3 CÁCH HẠN CHẾ DOWNTIME KHI LÊN ĐÁM MÂY

Di chuyển dữ liệu là một trong những phần phức tạp nhất trong đám mây. Trong quá trình di chuyển, vị trí dữ liệu có thể tác động đáng kể đến hiệu suất ứng dụng. Nếu không di chuyển dữ liệu cùng lúc di chuyển dịch vụ sử dụng dữ liệu, bạn đang mạo hiểm việc cần kết nối dữ liệu thông qua khoảng cách giữa hạ tầng on-premise và đám mây. Điều này có thể gây ra sự cố downtime.

Có ba cách chính để di chuyển dữ liệu ứng dụng sang đám mây:

1. Di chuyển bản sao offline
2. Di chuyển chuyển đổi master/read replica
3. Master/master migration

Không là vấn đề về việc di chuyển (CSDL) cơ sở dữ liệu SQL, noSQL hoặc đơn giản là các dữ liệu thô. Mỗi phương thức di chuyển đòi hỏi một sự nỗ lực khác nhau. Có tác động khác nhau đến tính khả dụng của ứng dụng và có các rủi ro khác nhau. Ba chiến lược khá giống nhau nhưng sự khác biệt nằm ở phần chi tiết.

CÁCH 1: DI CHUYỂN BẢN SAO OFFLINE

Di chuyển bản sao offline là phương pháp đơn giản nhất. Đưa ứng dụng on-premise xuống và sao chép dữ liệu trong đó sang CSDL đám mây. Sau đó đưa ứng dụng trở lại trực tuyến trên đám mây.

Di chuyển bản sao offline rất đơn giản, dễ dàng và an toàn. Nhưng phải để ứng dụng của mình offline để thực thi nó. Nếu tập dữ liệu quá lớn, ứng dụng có thể offline trong khoảng thời gian đáng kể. Điều này ảnh hưởng đến khách hàng và doanh nghiệp.

Với hầu hết các ứng dụng, lượng downtime cần cho di chuyển bản sao offline thường không được chấp nhận. Nếu dữ liệu đủ nhỏ, có thể chịu được lượng downtime và thì nên xem xét cách này. Đây là phương pháp dễ nhất, ít tốn kém nhất và ít rủi ro nhất khi di chuyển sang đám mây.

CÁCH 2: DI CHUYỂN REPLICA MASTER/READ

Mục tiêu của việc di chuyển chuyển master/read replica là để giảm thời gian downtime của ứng dụng. Đồng thời không làm phức tạp đáng kể việc di chuyển dữ liệu.

Đối với kiểu di chuyển này, bắt đầu với phiên bản master của cơ sở dữ liệu đang chạy trong hạ tầng on-premise. Sau đó, thiết lập một read replica của CSDL đám mây. Cùng với việc đồng bộ hóa dữ liệu một chiều từ master on-premise sang read replica. Ở thời điểm này, vẫn thực hiện tất cả các cập nhật và thay đổi dữ liệu cho master on-premise và master đồng bộ hóa các thay đổi đó với read replica trên đám mây. Mô hình master replica phổ biến trong hầu hết các hệ thống cơ sở dữ liệu.

Tiếp tục thực hiện ghi dữ liệu cho master on-premise. Ngay cả sau khi ứng dụng di chuyển và hoạt động trong đám mây. Tại một số thời điểm được xác định trước, chuyển đổi và trao đổi vai trò của master/read replica. Cơ sở dữ liệu đám mây trở thành master và CSDL on-premise trở thành read replica. Đồng thời chuyển tất cả quyền truy cập ghi từ on-premise sang CSDL đám mây.

Sẽ cần một khoảng thời gian ngừng hoạt động ngắn trong quá trình chuyển đổi. Nhưng downtime ít hơn đáng kể so với sao chép offline.

Tuy nhiên, downtime là downtime. Vì vậy cần đánh giá chính xác những gì doanh nghiệp có thể xử lý.

CÁCH 3: MASTER/MASTER MIGRATION

Là cách phức tạp nhất trong ba chiến lược di chuyển dữ liệu và có rủi ro cao. Tuy nhiên, nếu thực hiện một cách chính xác, có thể di chuyển dữ liệu mà không có downtime.

Với phương pháp này, bạn tạo một bản sao của master CSDL on-premise trong đám mây. Thiết lập đồng bộ hóa hai chiều giữa hai master, đồng bộ hóa tất cả dữ liệu từ on-premise sang đám mây, và từ đám mây xuống on-premise. Về cơ bản, còn lại với cấu hình CSDL multi-master điển hình.

Sau khi thiết lập cả hai cơ sở dữ liệu, có thể đọc và ghi dữ liệu từ on-premise hoặc CSDL đám mây. Cả hai sẽ vẫn được đồng bộ hóa. Điều này sẽ cho phép di chuyển các ứng dụng và dịch vụ một cách độc lập. Đồng thời không cần phải lo lắng về dữ liệu .

Để kiểm soát việc di chuyển tốt hơn, có thể chạy các phiên bản của ứng dụng trên on-premise và trên đám mây. Di chuyển traffic ứng dụng lên đám mây mà không có downtime. Nếu có vấn đề phát sinh, đảo ngược việc di chuyển, chuyển hướng traffic sang on-premise CSDL trong khi khắc phục sự cố.

Sau khi hoàn tất việc di chuyển, chỉ cần tắt master on-premise và sử dụng cloud master.

Cần lưu ý là phương pháp này có sự phức tạp. Nếu ứng dụng, dữ liệu và doanh nghiệp có thể đáp ứng cách thức di chuyển này thì đây là điều may mắn. Hãy sử dụng cách này. Đây là một trong những chiến lược sạch nhất và dễ nhất trong ba chiến lược.

GIẢM THIỂU RỦI RO KHI DI CHUYỂN

Bất kỳ di chuyển dữ liệu nào cũng đi kèm với một số rủi ro. Đặc biệt là rủi ro tham nhũng dữ liệu. Dữ liệu có nguy cơ đó cao nhất trong khi đang di chuyển. Đừng dừng cho đến khi hoàn thành xong quá trình hoặc đảo ngược hoàn toàn việc dịch chuyển. Không bao giờ dừng việc di chuyển giữa chừng.

Nguy cơ tham nhũng dữ liệu đặc biệt cao khi di chuyển các bộ dữ liệu cực lớn. Công cụ sao chép và truyền dữ liệu offline như AWS Snowball giúp quản lý di chuyển số lượng lớn dữ liệu. Nhưng lại không giúp được gì với các mẫu sử dụng dữ liệu ứng dụng trong quá trình di chuyển.

Với tất cả các lần di chuyển, không biết được nếu gặp phải sự cố không thể xem ứng dụng hoạt động trước, trong và sau khi di chuyển. Hiểu cách ứng dụng phản ứng với các bước trong quy trình di chuyển thì sẽ duy trì tính khả dụng của ứng dụng. Giữ cho dữ liệu an toàn và bảo mật.