> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/knowledge-base/vi/system-administration/cluster-recovery-after-power-outage.md).

# Khôi phục cụm sau khi mất điện hoàn toàn

## Tổng quan

{% hint style="info" %}
**Các điểm chính**

* Nên tránh tắt máy không đúng cách khi có thể, đặc biệt trên các hệ thống sản xuất.
* Hướng dẫn này cung cấp các thực hành tốt nhất -- nhằm giảm thiểu các vấn đề tiềm ẩn -- để bật lại cụm sau khi xảy ra một lần tắt máy đột ngột ngoài ý muốn.
* Bật nguồn **Node1** Trước hết. Hãy đợi 30 giây đến một phút, rồi bật các nút cụm còn lại.
* Một giá trị khác 0 **Sửa chữa** sau khi khôi phục là bình thường; nó sẽ giảm dần khi các Journal Walk hoàn tất.
* Hãy liên hệ Hỗ trợ VergeIO nếu số lượng Sửa chữa không trở về 0 khi hoàn tất Journal Walk hoặc nếu các bất thường khác vẫn tiếp diễn.
  {% endhint %}

## Phạm vi

Hướng dẫn này bao gồm việc bật lại cụm VergeOS sau một **lần tắt máy không đúng cách** -- khi cụm bị mất điện đột ngột do mất điện lưới, UPS cạn pin, sự cố cơ sở vật chất hoặc sự kiện tương tự. Đối với các quy trình tắt máy và bật nguồn đã lên kế hoạch, có kiểm soát, xem [Quy trình tắt hệ thống VergeOS đúng cách](/knowledge-base/vi/system-administration/proper-vergeos-system-shutdown-procedure.md) và [Trình tự bật/tắt nguồn đúng](/knowledge-base/vi/system-administration/proper-power-sequence-for-vergeos.md).

{% hint style="warning" %}
**Tránh tắt máy không đúng cách khi có thể**

* Mặc dù VergeOS có nhiều cơ chế bảo vệ tích hợp để giữ tính toàn vẹn dữ liệu, không có hệ thống lưu trữ phân tán nào có thể hoàn toàn đảm bảo chống lại hỏng dữ liệu khi các nút đồng thời mất điện đột ngột.
* Các lần ghi đang diễn ra tại thời điểm mất điện có thể chưa hoàn tất hoặc không nhất quán giữa các nút ngang hàng, và trong một số trường hợp con đường duy nhất để khôi phục tính toàn vẹn là đưa một volume trở lại một snapshot gần đây.
* Ngoài ra, các vấn đề về phần cứng, hệ điều hành guest và ứng dụng thường xảy ra sau các lần tắt máy không đúng cách.
* Cơ sở hạ tầng điện phù hợp -- dự phòng UPS đủ cho việc tắt máy an toàn, PSU dự phòng, và tự động tắt khi pin yếu -- là biện pháp bảo vệ hiệu quả nhất; xem phần [Phòng ngừa](#preventionmitigation) để biết hướng dẫn.
* Khi một lần tắt máy không đúng cách vẫn xảy ra dù đã có các biện pháp phòng ngừa này, quy trình sau đây được thiết kế để đưa cụm trở lại hoạt động một cách an toàn và phát hiện mọi vấn đề toàn vẹn cần được xử lý.
  {% endhint %}

## Điều kiện tiên quyết

* Quyền truy cập vật lý hoặc IPMI/BMC vào từng nút
* Biết nút nào là **Node1** (Node1 sẽ cần được khởi động trước.)
* Xác nhận rằng nguồn điện phía trên, mạng (các switch fabric lõi) và IPMI đã được khôi phục và ổn định
* Một snapshot cục bộ hoặc sao chép từ xa gần đây, phòng trường hợp phát hiện ra vấn đề về tính toàn vẹn
* Sự quen thuộc với [Bảng điều khiển vSAN Tier / Journal Walks](/knowledge-base/vi/storage-vsan/understanding-journal-walks-and-vsan-tier-status.md)

## Các bước

### Điều có thể mong đợi

* VergeFS bao gồm nhiều cơ chế bảo vệ tích hợp để giúp bảo toàn tính toàn vẹn dữ liệu trong các sự kiện mất điện -- bao gồm ghi nhật ký, sao chép ngang hàng, máy chủ sửa chữa (ioGuardian), và xác minh khi khởi động. Khi bộ điều khiển khởi động, VergeFS kích hoạt một **Journal Walk đầy đủ** để xác minh từng khối và đối chiếu với các nút ngang hàng. Các cơ chế bảo vệ này hiệu quả trong hầu hết các trường hợp, nhưng không có hệ thống lưu trữ phân tán nào có thể hoàn toàn đảm bảo chống lại hỏng dữ liệu do mất điện đột ngột; việc xác minh sau khi khởi động là rất quan trọng, đặc biệt sau một lần tắt máy không đúng cách.
* vSAN yêu cầu **Số nút tối thiểu** trực tuyến trước khi có thể gắn kết (ví dụ: Trong một cụm 4 nút với bảo vệ N+1, vSAN sẽ gắn kết miễn là có 3 nút trực tuyến) Cho đến khi đạt ngưỡng đó, bộ nhớ vẫn ngoại tuyến và các VM sẽ không khởi động.
* Node1 sẽ khởi động nhưng dừng lại trước khi gắn kết vSAN cho đến khi đủ các nút ngang hàng tham gia.
* Một giá trị khác 0 **Sửa chữa** số lượng sau khi khôi phục là bình thường và sẽ giảm dần khi quá trình Walk tiến triển.

### Các bước kiểm tra trước khi bật nguồn

{% hint style="warning" %}
**Xác minh rằng hạ tầng đã sẵn sàng trước**

Trước khi bật bất kỳ nút nào của cụm, hãy xác nhận rằng hai điều kiện quan trọng đã được đáp ứng. Những điều này đã được đề cập trong phần tiên quyết, nhưng cần nhắc lại ở đây -- bỏ qua chúng có thể gây ra thiệt hại nghiêm trọng hơn nhiều so với lần tắt máy ban đầu:

1. **Nguồn điện của cơ sở đã được khôi phục đầy đủ và ổn định.** Đưa cụm hoạt động trở lại trong khi nguồn điện vẫn còn không ổn định -- chập chờn, sụt áp, hoặc mất điện lần nữa -- có nguy cơ làm trầm trọng thêm vấn đề ban đầu và có thể dẫn đến các vấn đề toàn vẹn dữ liệu khác.

2. **Các switch mạng lõi đã được bật và khởi động hoàn tất.** Các switch doanh nghiệp có thể mất vài phút để hoàn tất quá trình khởi động, tương tự như một máy chủ. Nếu các nút cụm lên mạng trước khi mạng sẵn sàng, chúng sẽ không thể phát hiện các nút ngang hàng của mình, điều này có thể gây ra sự cố đối chiếu.
   {% endhint %}

3. Xác nhận **nguồn điện phía trên** ổn định. Đưa các nút lên khi nguồn cấp không ổn định có nguy cơ mất điện lần hai giữa quá trình khôi phục.

4. Xác nhận **các switch mạng lõi** đã trực tuyến, **khởi động hoàn tất**, và fabric giữa các nút đã hoạt động. vSAN không thể tái lập nếu không có nó, và các switch nâng cao có thể mất vài phút để khởi động xong.

5. Xác minh **IPMI/BMC** quyền truy cập trên từng nút để bạn có thể giám sát quá trình khởi động từ xa nếu cần.

6. Ghi chú mọi nút có lỗi phần cứng hiển thị rõ ràng (PSU hỏng, đèn LED ổ đĩa, cảnh báo quạt) -- những nút này có thể cần được xử lý trước khi được đưa trở lại.

### Trình tự bật nguồn

Sau khi đã xác nhận hạ tầng điện và mạng sẵn sàng:

1. **Bật Node1.**
   * Theo dõi console/IPMI. Node1 sẽ khởi động hệ điều hành nhưng **dừng trước khi gắn kết vSAN** cho đến khi đủ các nút ngang hàng tham gia.
2. **Chờ từ 30 giây đến 1 phút.**
   * Khoảng dừng ngắn này cho phép Node1 bắt đầu khởi tạo trước khi phần còn lại của cụm xuất hiện. Không cần đợi Node1 đi tới trạng thái dừng hoàn toàn trước khi tiếp tục.
3. **Bật các nút còn lại.**
   * Các nút còn lại có thể được bật cùng lúc (hoặc liên tiếp sát nhau); không cần bật lần lượt từng nút một.
   * vSAN sẽ tự động gắn kết ngay khi đạt số nút tối thiểu (ví dụ: tất cả trừ một nút trong cấu hình N+1 mặc định).
4. **Môi trường nhiều cụm:** đưa cụm điều khiển lên trạng thái hoạt động hoàn chỉnh trước khi bật các cụm bổ sung.

{% hint style="success" %}
**Mẹo nhỏ**

Node1 khởi động trước và chờ trong khi bạn bật các phần còn lại của cụm -- đó là điều bình thường, không phải trạng thái bị treo. vSAN sẽ tự gắn kết ngay khi đủ các nút ngang hàng trực tuyến, và VergeOS xử lý đối chiếu tự động; không cần lệnh sửa chữa thủ công.
{% endhint %}

### Xác minh sau khôi phục

Khi tất cả nút đã trực tuyến và cụm đã có thời gian ổn định, hãy xác minh rằng mọi thứ đã trở lại trạng thái khỏe mạnh. Vì cụm đã bị tắt máy không đúng cách, hãy thực hiện các kiểm tra này với sự thận trọng cao hơn -- mất điện đột ngột có thể để lại các sự cố mà cụm không thể tự giải quyết hoàn toàn. Hãy kiểm tra kỹ các lỗi vSAN kéo dài, các khối lượng công việc bị lỗi hoặc lặp vòng treo/crash, và mọi lỗi hệ thống tệp ở mức guest. Nếu phát hiện hỏng hóc không thể khắc phục, có thể cần phục hồi volume về một snapshot gần đây.

1. **Xác nhận tình trạng tổng thể của hệ thống**

   Mất điện đột ngột làm tăng nguy cơ sự cố phần cứng. Điều quan trọng là kiểm tra mọi vấn đề:

   * Xem lại [Cảnh báo](/run-the-platform/operations/alarms.md) trên bảng điều khiển. Xác nhận không có cảnh báo mới nào được kích hoạt.
   * Xem lại **nhật ký hệ thống (Bảng điều khiển chính)** để tìm lỗi trong quá trình khởi động hoặc gắn kết ban đầu.
2. **Xác minh tình trạng vSAN**
   * Mở **Bảng điều khiển chính** -- tất cả các đèn trạng thái nên là **Xanh lá**.
   * Điều hướng tới **Hệ thống → vSAN → Tầng** và nhấp đúp vào từng tầng.
   * Xem lại **ô** trên bảng điều khiển của từng tầng. Bài KB [Hiểu các lượt đi qua trạng thái/lịch sử nhật ký của tier vSAN](/run-the-platform/storage/vsan-diagnostics.md) cung cấp hướng dẫn đọc các trường trạng thái tầng vSAN.
3. **Xác minh tình trạng ổ đĩa**
   * Đi tới **Hệ thống → vSAN → Ổ đĩa**.
   * Tìm bất kỳ ổ đĩa nào hiển thị lỗi, cảnh báo hoặc cảnh báo SMART -- điều này có thể xảy ra khi ổ đĩa không quay lại sạch sẽ sau khi mất điện đột ngột.
   * **Thay thế các ổ đĩa lỗi** một cách kịp thời để duy trì bảo vệ dữ liệu vSAN.
4. **Xác minh khối lượng công việc**

   <div data-gb-custom-block data-tag="hint" data-style="success" class="hint hint-success"><p><strong>Hành vi tự động khởi động VM</strong></p><p>Theo mặc định, các VM được cấu hình để tự động khởi động khi nguồn điện được khôi phục cho cụm. Các VM có thiết lập <strong>Khi mất điện</strong> khác sẽ cần được bật thủ công.</p></div>

   * Xác minh các VM quan trọng: console phản hồi, hệ điều hành guest khỏe mạnh, dịch vụ ứng dụng hoạt động. Tắt máy không đúng cách có thể gây ra sự cố bên trong hệ điều hành guest và các ứng dụng đã cài đặt -- hãy chú ý lỗi hệ thống tệp, dịch vụ không khởi động được, và ứng dụng bị sập khi khởi chạy.
   * Xác định sớm nhất có thể các ứng viên tiềm năng để phục hồi về snapshot -- lý tưởng là trước khi các ứng dụng quay lại sử dụng nhiều.

{% hint style="warning" %}
**Quyết định khôi phục snapshot phụ thuộc vào thời gian**

Nếu hệ thống tổng thể hoặc từng VM riêng lẻ có dấu hiệu hư hại từ lần tắt máy không đúng cách mà không thể sửa chữa tại chỗ, khôi phục từ snapshot trước sự cố có thể là con đường duy nhất để trở lại trạng thái khỏe mạnh. **Việc xác định này nên được thực hiện càng sớm càng tốt**, vì hai lý do:

* **Thời gian lưu giữ snapshot là có hạn.** Một snapshot tiền sự cố còn dùng được có thể bị xoá vòng và trở nên không khả dụng nếu chần chừ quá lâu trước khi đưa ra quyết định.
* **Dữ liệu mới hơn sẽ bị mất khi khôi phục.** VM bị ảnh hưởng càng ở trong môi trường sản xuất lâu sau sự cố, thì càng nhiều công việc hợp lệ sau khôi phục bị loại bỏ khi thực hiện rollback.
  {% endhint %}

## Khắc phục sự cố

{% hint style="warning" %}
**Các sự cố thường gặp**

* **Vấn đề:** Một nút không thể gia nhập lại cụm.
  * **Giải pháp:** Kiểm tra đầu ra IPMI/console để tìm lỗi khởi động. Xác minh giao diện mạng lõi của nút đang hoạt động và có thể truy cập từ các nút ngang hàng. Xem **Hệ thống → Nút → \[nút]** để xem trạng thái và dấu thời gian lần cuối nhìn thấy. Nếu nút khởi động nhưng không tham gia, đừng **không** buộc xóa nó -- hãy liên hệ hỗ trợ.
* **Vấn đề:** vSAN không gắn kết / bộ nhớ ngoại tuyến.
  * **Giải pháp:** Xác nhận **Số nút vSAN tối thiểu** trong **Hệ thống → Nút** (ví dụ: trong cấu hình mặc định: 3 trong 4 nút ở cụm 4 nút, 5 trong 6 ở cụm 6 nút). Xác nhận kết nối giữa các nút (các switch fabric lõi, trạng thái liên kết, MTU). Nếu đã đạt ngưỡng nhưng bộ nhớ vẫn không gắn kết, hãy thu thập sysdiag và liên hệ hỗ trợ.
* **Vấn đề:** Số lượng sửa chữa bị kẹt hoặc tăng lên.
  * **Giải pháp:** Một số lượng nhỏ, giảm dần **Sửa chữa** là bình thường sau khôi phục. Một số lượng **ngừng giảm** hoặc **tăng lên** cho thấy các khối mà vSAN không thể tái tạo từ các nút ngang hàng. **Không khởi động lại bất kỳ nút nào.** Liên hệ hỗ trợ trước khi thực hiện các bước khắc phục.
* **Vấn đề:** Nghi ngờ split-brain hoặc trạng thái cụm không nhất quán.
  * **Giải pháp:** Trong quá trình khôi phục, một sự cố mạng có thể khiến hai nhóm nút khởi động lên mà không nhìn thấy nhau. Nếu bạn thấy dấu hiệu hình thành hai cụm độc lập (hiếm, nhưng có thể xảy ra sau khi khôi phục mạng một phần), **đừng cố gắng tự hợp nhất chúng**. Thu thập sysdiag từ mọi nút và liên hệ hỗ trợ ngay lập tức.
    {% endhint %}

## Phòng ngừa/Giảm thiểu

* **Kích thước và phạm vi phủ của UPS** -- thiết kế UPS đủ để bao phủ thời gian tắt máy an toàn cộng thêm biên độ cho từng nút. Bao gồm cả các switch mạng lõi trong cùng phạm vi bảo vệ. Kiểm tra thời gian chạy của UPS hằng năm -- pin sẽ xuống cấp.
* **Tự động tắt máy an toàn** -- Sử dụng phần mềm quản lý UPS (NUT, script IPMI, hoặc agent của nhà cung cấp UPS trên máy chủ quản trị) để phát hiện sự kiện pin yếu và kích hoạt việc tắt cụm an toàn -- thông qua hành động của Bảng điều khiển Cụm **Tắt nguồn** hành động, API VergeOS (`POST /v4/cluster_actions` với body `{"cluster": <cluster_id>, "action": "shutdown", "params": "{}"}`), hoặc trình bao bọc [**VRG CLI**](https://github.com/verge-io/vrg) , có thể tự động hóa cùng lệnh tắt máy từ một máy chủ Linux/macOS/Windows. Hãy kiểm tra tính tự động hóa trong một cửa sổ bảo trì trước khi dựa vào nó.
* **Các thiết lập VM "Khi mất điện"** -- cấu hình hành vi của từng VM một cách có chủ đích để trạng thái sau khôi phục có thể dự đoán được. Ba tùy chọn:
  * ***Trạng thái cuối cùng*** -- VM chỉ bật nếu nó đang bật vào thời điểm mất điện
  * ***Để tắt*** -- VM vẫn tắt khi nguồn được khôi phục, bất kể trạng thái trước đó
  * ***Bật nguồn*** -- VM sẽ bật khi nguồn được khôi phục, bất kể trạng thái trước đó
* **Máy chủ sửa chữa (ioGuardian)** -- một [máy chủ sửa chữa](/automate-protect-and-extend/backup-and-dr/repair-server.md) cung cấp cho VergeFS một nguồn dự phòng cho các khối bị thiếu nếu các nút ngang hàng không thể cung cấp chúng sau sự cố. Nó được xây dựng từ cấu hình đồng bộ site đi hiện có và kéo các khối cần thiết từ một hệ thống VergeOS từ xa đã được đồng bộ. Máy chủ sửa chữa được khuyến nghị mạnh mẽ cho bất kỳ triển khai sản xuất nào.
* **Xoay vòng snapshot đầy đủ** -- duy trì lịch lưu giữ snapshot sao cho các snapshot gần đây, trước sự kiện vẫn có sẵn để khôi phục khi cần. Việc sao chép snapshot sang một site từ xa cũng được khuyến nghị như một phần của chiến lược bảo vệ dữ liệu toàn diện.

## Khi nào nên liên hệ hỗ trợ

Mở một yêu cầu hỗ trợ **trước** khi khởi động lại các nút, hoặc thực hiện bất kỳ thay đổi đáng kể nào khác, nếu bất kỳ điều nào sau đây đúng:

* vSAN không gắn kết sau khi N nút đã trực tuyến (ví dụ: số nút đầy đủ trừ một trong cấu hình dự phòng N+1 mặc định)
* Một tầng hiển thị **Dự phòng: sai** trong một thời gian dài sau khi hoàn tất các Full Walk
* Tham số **Sửa chữa** số lượng bị kẹt hoặc tăng lên
* Có cảnh báo sửa chữa bị kẹt (VergeOS v26+)
* Nhiều ổ đĩa báo lỗi sau khôi phục
* Bạn nghi ngờ split-brain hoặc trạng thái cụm không nhất quán
* Bất kỳ nút nào không thể gia nhập lại và nguyên nhân không rõ ràng là do phần cứng

## Tạo Chẩn đoán hệ thống để hỗ trợ

Trước khi mở yêu cầu, hãy thu thập một sysdiag và đính kèm nó (hoặc gửi trực tiếp cho hỗ trợ):

Xem [Tạo chẩn đoán hệ thống](/knowledge-base/vi/troubleshooting/generating-system-diagnostics.md) và toàn bộ [Chẩn đoán Hệ thống](/run-the-platform/system-administration/diagnostics.md) tham chiếu.

## Tài nguyên bổ sung

* [Trình tự bật/tắt nguồn đúng](/knowledge-base/vi/system-administration/proper-power-sequence-for-vergeos.md)
* [Quy trình tắt hệ thống VergeOS đúng cách](/knowledge-base/vi/system-administration/proper-vergeos-system-shutdown-procedure.md)
* [Hiểu Journal Walk và trạng thái tầng vSAN](/knowledge-base/vi/storage-vsan/understanding-journal-walks-and-vsan-tier-status.md)
* [Tạo chẩn đoán hệ thống](/knowledge-base/vi/troubleshooting/generating-system-diagnostics.md)
* [Máy chủ sửa chữa (ioGuardian)](/automate-protect-and-extend/backup-and-dr/repair-server.md)
* [Hướng dẫn chẩn đoán vSAN](/run-the-platform/storage/vsan-diagnostics.md)

## Phản hồi

{% hint style="info" %}
**Cần trợ giúp?**

Nếu bạn cần thêm hỗ trợ hoặc có bất kỳ câu hỏi nào về bài viết này, xin đừng ngần ngại liên hệ với đội hỗ trợ của chúng tôi.
{% endhint %}

***

{% hint style="info" %}
**Thông tin tài liệu**

* Cập nhật lần cuối: 2026-05-08
* Phiên bản vergeOS: 26.0+
  {% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.verge.io/knowledge-base/vi/system-administration/cluster-recovery-after-power-outage.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.