Cách Chọn Kế hoạch Dự phòng Để Đảm bảo Tính sẵn có Cao
Trong phần đầu tiên của bài viết này, ta đã thảo luận về các giải pháp khác nhau để backup dữ liệu trên VPS của bạn.Bài viết này sẽ khám phá ý tưởng về sự dư thừa. Dữ liệu dự phòng không phải là bản backup , nhưng có thể cung cấp cho bạn chuyển đổi dự phòng trong trường hợp phương pháp truy cập dữ liệu chính của bạn không khả dụng.
Cách bạn chọn triển khai sao chép trên hệ thống của bạn chủ yếu phụ thuộc vào cách bạn đang sử dụng dữ liệu của bạn , những lỗi nào bạn muốn đề phòng và cách khách truy cập của bạn tương tác với các version server của bạn.
Dự phòng RAID
Có lẽ kiểu sao chép phổ biến nhất là RAID . RAID là viết tắt của mảng đĩa độc lập dự phòng. Điều này nghĩa là trong hầu hết các cấu hình, các đĩa phản chiếu lẫn nhau theo cách này hay cách khác.
Việc triển khai RAID dự phòng cơ bản nhất là một mảng RAID 1. Loại mảng này phản chiếu một đĩa trên một đĩa khác. Điều này nghĩa là nếu một đĩa bị lỗi, đĩa kia vẫn sẵn sàng để phục vụ và ghi dữ liệu. Loại mảng này tăng tốc độ đọc do thực tế là hệ thống có thể đọc từ một trong hai vị trí dữ liệu.
Ví dụ này cũng là một ví dụ tuyệt vời về lý do tại sao RAID và các cài đặt dự phòng nói chung không phải là các bản backup thích hợp. Nếu bạn xóa một file , nó sẽ không xuất hiện . Mọi thay đổi được áp dụng cho cả hai đĩa ngay lập tức.
Sao chép RAID được triển khai ở mức thấp, vì vậy bạn sẽ không có quyền kiểm soát việc triển khai RAID trên VPS DigitalOcean.
Dự phòng cấp khối
Một phương pháp cung cấp dự phòng khác là phản chiếu toàn bộ cấu trúc khối. DRBD , hoặc thiết bị khối sao chép phân tán, là một cách để đạt được sự dự phòng trên các thiết bị khối.
Điều này có vẻ tương tự như một mảng RAID được nhân bản và theo một số cách, nó là như vậy. Sự khác biệt nằm ở nơi diễn ra quá trình nhân rộng. Với RAID, dự phòng diễn ra dưới mức ứng dụng. Thẻ RAID hoặc phần mềm RAID quản lý các thiết bị lưu trữ vật lý và hiển thị ứng dụng với một thiết bị rõ ràng duy nhất.
Mặt khác, DRBD được cấu hình theo một cách hoàn toàn khác. Trong cài đặt DRBD, mỗi ngăn xếp phần cứng được sao chép hoàn toàn. Giao diện ứng dụng cũng được sao chép. Điều này nghĩa là lỗi ứng dụng có thể được xử lý vì có một máy hoàn toàn riêng biệt với bản sao dữ liệu để làm việc. Nếu server đầu tiên của bạn gặp sự cố cấp nguồn, server thứ hai vẫn hoạt động hiệu quả.
Sao chép SQL
Nếu dữ liệu quan trọng của bạn được lưu trữ trong database SQL (MySQL, MariaDB, PostgreSQL, v.v.), bạn có thể tận dụng một số tính năng sao chép tích hợp sẵn. Chúng được dùng để cung cấp hệ thống chuyển đổi dự phòng trong trường hợp server chính gặp sự cố.
Master-Slave Replication
Loại sao chép SQL cơ bản nhất là cấu hình Master-Slave. Trong trường hợp này, bạn có một server database chính, được gọi là server “chính”. Server này chịu trách nhiệm thực hiện tất cả các lần ghi và cập nhật. Dữ liệu từ server này được sao chép liên tục sang server “ slaver ”. Server này có thể được đọc từ, nhưng không được ghi vào.
Cài đặt này cho phép bạn phân phối các lần đọc trên nhiều máy, điều này có thể cải thiện đáng kể hiệu suất ứng dụng của bạn.
Mặc dù sự gia tăng hiệu suất này là một lợi thế, nhưng một trong những lý do chính mà bạn có thể cài đặt bản sao master-slave là để xử lý chuyển đổi dự phòng. Nếu server chính của bạn không khả dụng, bạn vẫn có thể đọc từ server phụ của bạn . Hơn nữa, có thể chuyển đổi slaver thành server chính trong trường hợp server của bạn offline trong một khoảng thời gian dài.
Thực tế, sao chép Master-slave là một lĩnh vực mà ta bắt đầu thấy cách dự phòng và backup có thể bổ sung cho nhau. Trong cấu hình master-slave, bạn có thể sao chép dữ liệu từ master sang slave. Sau đó, bạn có thể tạm thời vô hiệu hóa sao chép để duy trì trạng thái thông tin nhất quán trên slaver . Từ đây, bạn có thể backup database bằng bất kỳ cơ chế backup nào phù hợp.
Để tìm hiểu thêm về cách cấu hình bản sao MySQL master-slave , hãy nhấp vào đây. Để tìm hiểu về cách thực hiện sao chép master-slave với PostgreSQL , hãy nhấp vào liên kết này.
Bản sao Master-Master
Một hình thức sao chép thứ hai được gọi là sao chép Master-Master. Cấu hình này cho phép cả hai server có khả năng "chính". Điều này nghĩa là mỗi server có thể chấp nhận ghi và cập nhật và sẽ chuyển các thay đổi sang server đối diện. Cấu hình này kế thừa những ưu điểm của cài đặt master-slave, nhưng cũng được hưởng lợi từ việc tăng hiệu suất ghi nếu việc ghi được phân phối đúng cách bởi cơ chế cân bằng tải.
Điều này cũng nghĩa là , trong trường hợp một server gặp sự cố, server kia vẫn hoạt động và sẵn sàng chấp nhận yêu cầu. Trong khi cấu hình phức tạp hơn, việc chuyển đổi dự phòng trong trường hợp có sự cố sẽ ít phức tạp hơn so với dự phòng master-slave, vì database slave không cần phải chuyển đổi thành master.
Cấu hình này cũng có thể được kết hợp với cơ chế backup nếu bạn sử dụng một trong các server chính offline . Bạn phải duy trì một database tĩnh để backup hoạt động chính xác, vì vậy bạn phải đảm bảo không có dữ liệu nào được sửa đổi hoặc ghi vào cho đến sau khi backup hoàn tất.
Để biết thêm thông tin về cách cấu hình bản sao tổng thể , bấm vào đây.
Phân phối như một giải pháp thay thế dự phòng
Hệ thống phân tán cung cấp nhiều ưu điểm của cài đặt dự phòng truyền thống.
Ta đã thảo luận về các mức RAID được sao chép ở trên (RAID 1). Một mức RAID phổ biến khác là RAID 5. RAID này phân phối dữ liệu trên một số ổ đĩa và cũng ghi tính chẵn lẻ của dữ liệu trên mỗi ổ đĩa. Điều này nghĩa là bất kỳ loại giao dịch nào cũng có thể được “xây dựng lại” từ việc kết hợp thông tin chẵn lẻ trên các ổ đĩa khác nếu một ổ đĩa đơn bị chết.
Điều này cung cấp một cách khác để phân phối dữ liệu trên các đĩa và cũng có thể xử lý một lỗi đĩa đơn.
Hệ thống phân tán không nhất thiết phải dựa trên phần cứng. Ngoài ra còn có khá nhiều database và các giải pháp phần mềm khác được thiết kế với dữ liệu phân tán như một tính năng chính.
Một ví dụ về điều này là Riak, một database phân tán. Các node Riak đều giống nhau. Không có mối quan hệ chủ-nô giữa các phần khác nhau. Các đối tượng được lưu trữ trong database được sao chép, vì vậy có sự dư thừa truyền thống về mặt đó.
Tuy nhiên, mỗi nút không chứa toàn bộ database . Thay vào đó, dữ liệu được phân phối giữa các node theo cách đồng đều. Các đối tượng được sao chép được đặt trên các node khác nhau để cho phép sẵn sàng trong trường hợp lỗi phần cứng.
Một ví dụ tuyệt vời khác về khái niệm này được thực hiện trong database là Cassandra. Nó dựa trên các nguyên tắc tương tự như Riak, nhưng được thực hiện theo một cách khác.
Kết luận
Như bạn thấy , có nhiều tùy chọn để dự phòng, mỗi tùy chọn đều có ưu điểm và khuyết điểm. Nó chủ yếu phụ thuộc vào những vấn đề bạn đang cố gắng dự đoán và những phần nào trong hệ thống của bạn mà bạn coi là một lỗi không thể chấp nhận được. Như bạn có thể tưởng tượng, sự kết hợp của một số kỹ thuật này sẽ luôn mang lại một mạng lưới an toàn toàn diện hơn.
Bạn cũng có thể thấy rằng các cài đặt dự phòng không thể thay thế cho các bản backup . Nhu cầu về các hệ thống dự phòng luôn hoạt động và luôn phản chiếu các thay đổi có thể dễ dàng cho phép hủy dữ liệu từ tất cả các điểm trong cấu hình của bạn.
Đối với các ứng dụng mà tính toàn vẹn của dữ liệu và quyền truy cập là cần thiết, cả dự phòng và backup đều vô giá. Việc triển khai đúng cách sẽ đảm bảo sản phẩm của bạn luôn có sẵn cho user và dữ liệu quan trọng sẽ không bao giờ bị mất.
<div class = “author”> Bởi Justin Ellingwood </div>
Các tin liên quan
