Chiến lược sao lưu Amazon EC2 với các hạn chế (có thể thực hiện ít ảnh chụp nhanh không?)

Các câu hỏi tương tự đã được hỏi nhưng tôi cần biết những gì sẽ được đề xuất trong các trường hợp, để biết liệu tôi có thiếu điều gì trong cách hiểu về việc sử dụng EC2 không.

Một startup nhỏ đang điều hành doanh nghiệp của họ trên mạng EC2 và hỏi tôi một số lời khuyên về các tùy chọn sao lưu. Hiện tại họ đang tự tài trợ và đang làm những gì có thể để tiết kiệm chi phí khi khả thi. Không đi sâu vào cấu hình hệ thống của họ, tôi sẽ lấy một máy chủ web làm ví dụ; đó là một máy chủ web đơn giản với cơ sở dữ liệu. Chà là họ không muốn máy chủ bị gỡ xuống.

Người đã thực hiện thiết lập tin rằng họ chỉ nên thực hiện việc kết xuất cơ sở dữ liệu định kỳ và lưu trữ trên S3 hoặc tạo tập lệnh sẽ xây dựng lại máy chủ mới trên Amazon khi cần bằng cách sao lưu các thư mục chọn chứa thông tin cấu hình . Ông cho rằng để tạo ảnh chụp nhanh của máy chủ sẽ lãng phí, vì chúng chiếm nhiều dung lượng đĩa và về cơ bản sẽ có sự luân chuyển dữ liệu giữa các bãi dữ liệu lớn để ảnh chụp nhanh sẽ bị lỗi thời.

Suy nghĩ của tôi là chụp ảnh VM, và sau đó thực hiện các bản ghi định kỳ của cơ sở dữ liệu và lưu trữ trong S3. Nếu họ mất phiên bản EC2 hoặc có một cái gì đó như bản cập nhật khiến nó không thể sử dụng được, họ có thể sử dụng ảnh chụp nhanh để xây dựng máy chủ sao lưu tương đối nhanh chóng với kết xuất cơ sở dữ liệu mới nhất, thay vì bắt đầu từ đầu để xây dựng một phiên bản mới từ một bản sao hoàn toàn mới AMI mới.

Sự hiểu biết của tôi là việc chụp một ví dụ EC2 (hoặc cửa hàng EBS) sẽ yêu cầu thời gian chết, điều mà họ đang do dự. Tôi cũng đã đọc rằng bạn nên tắt máy chủ để giữ cho hệ thống tập tin nhất quán khi chụp ảnh nhanh. Vì chúng chưa có cụm phía sau bộ cân bằng, nên chúng giới hạn các tùy chọn liên quan đến ảnh chụp nhanh.

Lập trình để xây dựng máy chủ, trừ khi có điều gì đó cụ thể đối với Amazon mà tôi không biết, sẽ liên quan đến việc tạo một máy chủ Chef hoặc Puppet có thể triển khai các máy chủ mới với vai trò liên quan của chúng trên EC2. Ngay bây giờ, startup không có kinh phí để giữ loại máy chủ đó trong cánh và họ, ngay bây giờ, không thực sự cần phải triển khai nhiều máy chủ đó.

Lý tưởng nhất là họ sẽ có kinh phí để tạo ra một số máy chủ đằng sau bộ cân bằng ảo hoặc dịch vụ cân bằng ảo của Amazon, sau đó gỡ từng máy chủ xuống để thực hiện cập nhật hoặc chụp nhanh. Ngay bây giờ tôi rất lo lắng về ý tưởng thực hiện cập nhật bởi vì nếu bạn thực hiện việc hủy bỏ cơ sở dữ liệu, điều đó sẽ không hữu ích nếu một bản cập nhật hệ thống thay đổi thư viện mà ứng dụng của họ dựa vào và dịch vụ bị hỏng.

Tôi cũng cho rằng một tùy chọn khác là chạy tập lệnh tạo âm lượng EBS, gắn kết nó và trên máy chủ chạy một cái gì đó như rsync để thu hầu hết thông tin hệ thống tệp vào ổ EBS sau đó nén và sao chép nội dung vào S3, ngắt kết nối ổ đĩa và phá hủy nó để tiết kiệm chi phí lưu trữ, sau đó thực hiện kết xuất cơ sở dữ liệu để bắt dữ liệu trên chuyến bay không nhất quán. Đối với một số máy chủ của họ, rất có thể sẽ cần phải lưu vào khối lượng EBS tạm thời khi nhu cầu cơ sở dữ liệu của họ tăng lên.

Một hộp cát VMWare đang được tạo để tái tạo các hệ thống mạng của họ trong môi trường mà các bản cập nhật có thể được kiểm tra trước khi áp dụng chúng vào các hệ thống sản xuất trên Amazon. Tôi hy vọng rằng sẽ giảm thiểu khả năng một bản cập nhật hệ thống sẽ giết chết ứng dụng của họ.

Vì vậy, ... đưa ra các hạn chế khi chạy một máy chủ, với cơ sở dữ liệu và máy chủ ứng dụng trên hệ thống, mong muốn càng gần thời gian chết càng tốt (hạn chế sử dụng ảnh chụp nhanh và có quá trình sao lưu càng "nóng" càng tốt ( được tạo trực tiếp mà không làm hỏng máy chủ), tôi có đang đi sai hướng khi đề xuất lập lịch trình thời gian để tạo ảnh chụp nhanh của cá thể EC2 ở trạng thái hoạt động và từ đó thực hiện các cơ sở dữ liệu để sao chép sang S3? trong việc tạo bản sao lưu trực tiếp của máy chủ nếu ảnh chụp nhanh sẽ tạo ra thời gian chết?

Có một điều thú vị về câu hỏi này - đặc biệt liên quan đến ý tưởng về thời gian chết. Một phần ý tưởng là nếu một ứng dụng nhạy cảm với thời gian chết, thì thời gian phục hồi cũng phải được tính đến. (Như một lập luận cực đoan, không có bản sao lưu nào không cần thời gian chết, trừ khi bạn tình cờ cần những bản sao lưu đó, trong trường hợp thời gian chết có thể đạt đến vô hạn ).

Một chút về EBS

Khối lượng và ảnh chụp nhanh EBS hoạt động ở cấp độ khối - hệ quả của việc cho phép chụp ảnh nhanh trong khi một phiên bản đang chạy, ngay cả khi khối lượng EBS đang được sử dụng. Tuy nhiên, chỉ có dữ liệu thực sự trên đĩa (tức là không có trong bộ đệm tệp) mới được đưa vào ảnh chụp nhanh. Đó là lý do thứ hai làm nảy sinh ý tưởng về ảnh chụp nhanh nhất quán.

• Cách được đề xuất là tách âm lượng, chụp nhanh và gắn lại - thường không thực tế.
• Tùy chọn tốt nhất tiếp theo liên quan đến việc xóa bộ đệm ghi vào đĩa, đóng băng hệ thống tệp và chụp ảnh nhanh của bạn

Một điểm thú vị ở đây là trong cả hai trường hợp trên, bạn không cần đợi ảnh chụp nhanh kết thúc để gắn lại / giải nén và tiếp tục ghi vào đĩa - một khi ảnh chụp nhanh được bắt đầu, dữ liệu của bạn sẽ phù hợp với thời điểm đó. Thông thường, điều này chỉ cần một vài giây trong đó đĩa của bạn bị khóa. Ngoài ra, vì hầu hết các cơ sở dữ liệu cấu trúc các tệp của họ trên đĩa một cách hợp lý - rất có thể các phần chèn có ảnh hưởng tối thiểu đến các khối hiện có - giúp giảm thiểu dữ liệu được thêm vào ảnh chụp nhanh.

Xem xét điểm của bản sao lưu

Khối lượng EBS đã được sao chép trong vùng khả dụng - do đó, có một mức độ dự phòng được tích hợp. Nếu trường hợp của bạn chấm dứt, bạn có thể chỉ cần gắn âm lượng EBS vào một thể hiện mới và (sau khi bạn vượt qua sự thiếu nhất quán) tiếp tục rời khỏi. Về nhiều mặt, điều này làm cho âm lượng EBS giống như một ảnh chụp nhanh không nhất quán, miễn là bạn có thể truy cập nó. Điều đó nói rằng, hầu hết người dùng EC2 có thể nhớ lại các thất bại xếp tầng của khối lượng EBS từ đầu năm 2011 - khối lượng không thể truy cập trong nhiều ngày và một số người dùng cũng bị mất dữ liệu.

RAID1

Nếu bạn đang cố gắng bảo vệ chống lại sự thất bại của đĩa EBS (điều đó xảy ra), bạn có thể xem xét thiết lập RAID1. Vì khối lượng EBS là các thiết bị khối, bạn có thể dễ dàng sử dụng mdadm để thiết lập chúng trong cấu hình mong muốn của bạn. Nếu một trong các khối EBS của bạn không hoạt động theo thông số kỹ thuật, thì có thể dễ dàng thất bại theo cách thủ công (và sau đó thay thế nó bằng một khối EBS khác). Tất nhiên, điều này có nhược điểm - tăng thời gian cho mỗi lần viết, độ nhạy cao hơn đối với hiệu suất biến đổi, tăng gấp đôi chi phí I / O (monetariliy, không phải hiệu năng), không có sự bảo vệ thực sự trước thất bại AWS phổ biến hơn (một vấn đề phổ biến năm ngoái là không có khả năng tách các khối EBS ở trạng thái bị khóa) và tất nhiên, trạng thái không nhất quán của đĩa bị lỗi.

S3FS

Một tùy chọn cho một số ứng dụng nhất định (chắc chắn KHÔNG dành cho cơ sở dữ liệu) là gắn S3 như một hệ thống tệp cục bộ (ví dụ: thông qua s3fs). Điều này chậm, thiếu một số tính năng mà người ta mong đợi từ một hệ thống tệp và có thể không hoạt động như mong đợi (tính nhất quán cuối cùng). Điều đó nói rằng, với mục đích đơn giản như làm cho các tệp được tải lên có sẵn trên các phiên bản, nó có thể có giá trị. Rõ ràng nó không dành cho bất cứ thứ gì đòi hỏi hiệu năng đọc / ghi tốt.

Nhật ký bin của MySQL

Thêm một tùy chọn cụ thể cho MySQL có thể là việc sử dụng bin-log. Bạn có thể thiết lập một khối EBS thứ hai sẽ lưu trữ nhật ký bin của bạn (để giảm thiểu ảnh hưởng của việc ghi được thêm vào cơ sở dữ liệu của bạn) và sử dụng kết hợp với bất kỳ cơ sở dữ liệu nào bạn sử dụng. Bạn thậm chí có thể làm điều này với s3fs, điều này thực sự có thể có hiệu quả nếu hiệu suất có thể chấp nhận được (một rsync có thể sẽ tốt hơn mặc dù cố gắng sử dụng s3fs trực tiếp và bạn chắc chắn sẽ muốn nén những gì bạn có thể).

Tuy nhiên, một lần nữa, chúng ta trở lại với ý tưởng về mục đích. Xem xét những gì sẽ xảy ra với các đề xuất trên:

• Khối lượng EBS không thể truy cập:
  • RAID1 - vô dụng, vì bạn không thể lấy dữ liệu
  • bin-log - vô dụng, trừ khi bạn xuất nó sang S3 - có thể là sự chậm trễ mặc dù nếu bạn đã làm điều đó
• Sơ thẩm chấm dứt bất ngờ:
  • RAID1 - đĩa của bạn có sẵn, nhưng không nhất quán, cơ sở dữ liệu của bạn có thể tự phục hồi từ sự không nhất quán
  • bin-log - dữ liệu của bạn sẽ có thể truy cập được, mặc dù bạn có thể cần xem lại một vài sự kiện vừa qua
• Ai đó chạy DROP DATABASE với quyền root:
  • RAID1 - bạn có hai bản sao hoàn hảo của cơ sở dữ liệu không tồn tại
  • bin-log - bạn sẽ có thể phát lại các sự kiện ngay trước lệnh, vì vậy bạn sẽ ổn thôi

Vì vậy, thực sự, RAID1 hầu như vô dụng và bin-log mất quá nhiều thời gian - cả hai có thể có công trong một số trường hợp nhất định, nhưng khác xa với bản sao lưu ý tưởng.

Ảnh chụp nhanh

Điều quan trọng cần lưu ý là ảnh chụp nhanh là vi sai và chỉ lưu trữ các khối thực có chứa dữ liệu (và được nén). Không giống như âm lượng EBS, trong đó nếu bạn có dung lượng 20 GB, nhưng chỉ sử dụng 1 GB, bạn vẫn bị tính phí cho bộ nhớ 'được cung cấp' (20 GB). Với một ảnh chụp nhanh, bạn chỉ bị tính phí cho những gì bạn sử dụng. Nếu không có dữ liệu thay đổi giữa các ảnh chụp nhanh, về mặt lý thuyết sẽ không có phí. (Ảnh chụp nhanh được tính cho PUTS / GETS và bộ nhớ đã sử dụng).

Bên cạnh đó, tôi rất khuyến nghị dữ liệu ứng dụng của bạn (bao gồm cả cơ sở dữ liệu) không được lưu trữ trên ổ đĩa gốc của bạn (mà bạn có thể đã thiết lập). Một trong những lợi thế là, hy vọng, khối lượng gốc của bạn nhìn thấy tối thiểu thay đổi - có nghĩa là ảnh chụp nhanh của nó có thể ít thường xuyên hơn (hoặc sẽ có tối thiểu thay đổi) giảm chi phí và dễ sử dụng.

Cũng có liên quan để đề cập rằng bạn có thể xóa các ảnh chụp nhanh cũ bất cứ lúc nào - mặc dù chúng là khác biệt nhưng chúng sẽ không ảnh hưởng đến các ảnh chụp nhanh khác. Điều đó nói rằng, mỗi khối được phân bổ cho một ảnh chụp nhanh sẽ không bị hủy bỏ cho đến khi không có ảnh chụp nhanh nào vẫn tham chiếu khối đó.

Vấn đề với các bãi định kỳ trước hết là thời gian giữa các lần đổ (có thể được giải quyết bằng cách sử dụng nhật ký bin của MySQL) và cũng là khó khăn trong việc phục hồi. Phải mất thời gian để nhập một bãi chứa lớn và phát lại tất cả các sự kiện từ nhật ký bin. Ngoài ra, tạo ra một bãi chứa không phải là không có ý nghĩa hiệu suất của nó. Có thể cho rằng, các bãi như vậy có thể yêu cầu lưu trữ nhiều hơn nhiều so với ảnh chụp nhanh. Thiết lập một khối EBS chỉ dành cho cơ sở dữ liệu và chụp nhanh có thể thích hợp hơn trong hầu hết các trường hợp (có nghĩa là, chụp ảnh nhanh cũng có một chút hàm ý về hiệu suất).

Vẻ đẹp của ảnh chụp nhanh và khối lượng EBS là chúng có thể được sử dụng trong các trường hợp khác. Nếu phiên bản của bạn không khởi động được, bạn có thể đính kèm ổ đĩa gốc vào một phiên bản khác để chẩn đoán và khắc phục sự cố - hoặc chỉ để sao chép dữ liệu của bạn khỏi nó - và có thể chuyển đổi khối lượng gốc chỉ với một vài phút ngừng hoạt động (dừng phiên bản, tách ra khối lượng gốc, đính kèm một khối lượng gốc mới, bắt đầu thể hiện). Ý tưởng tương tự này áp dụng để có dữ liệu của bạn trên một khối EBS thứ hai. Về cơ bản, bạn chỉ cần quay một phiên bản mới từ AMI tùy chỉnh của mình và đính kèm âm lượng EBS hiện tại của bạn vào nó - nó giúp giảm thiểu thời gian chết.

(Người ta có thể đưa ra lập luận (và tôi có thể không khuyến nghị) rằng bạn có thể thiết lập hai bản sao của MySQL trên cùng một máy chủ (Master-Slave), sử dụng hai tập EBS, sau đó tắt nô lệ của bạn để chụp ảnh nhanh Khối lượng EBS - nó sẽ phù hợp, không có thời gian chết - nhưng chi phí hiệu suất có thể không xứng đáng).

AWS có chế độ tự động hóa - sẽ có thể duy trì số lượng phiên bản không đổi (ngay cả khi số đó là 1) - tuy nhiên, bạn sẽ triển khai từ ảnh chụp nhanh - vì vậy nếu ảnh chụp nhanh của bạn không hữu ích, thì tiền đề không được sử dụng nhiều .

Một vài điểm khác - bạn có thể triển khai bao nhiêu trường hợp bạn muốn từ một ảnh chụp nhanh (không giống như âm lượng EBS, chỉ có thể được gắn vào một thể hiện tại bất kỳ thời điểm nào). Ngoài ra, khối lượng EBS bị hạn chế sử dụng trong vùng khả dụng, trong khi ảnh chụp nhanh có thể được sử dụng trong một vùng.

Lý tưởng nhất là với ảnh chụp nhanh, nếu máy chủ của bạn gặp sự cố, bạn có thể khởi chạy một ảnh mới bằng cách sử dụng ảnh chụp nhanh cuối cùng - đặc biệt là nếu bạn tách khối lượng gốc khỏi dữ liệu của mình, một bản cập nhật xấu sẽ dẫn đến tối thiểu thời gian chết (vì bạn sẽ chuyển khối lượng EBS chứa dữ liệu của bạn qua - và chụp ảnh nhanh để bảo toàn mọi thứ có thể bị hỏng do không thống nhất).

Là một lưu ý phụ, Amazon tuyên bố tỷ lệ thất bại của khối lượng EBS tăng lên cùng với lượng dữ liệu thay đổi trên chúng kể từ ảnh chụp nhanh cuối cùng.

Khuyến nghị cuối cùng

• Sử dụng ảnh chụp nhanh - chúng rất tuyệt - chúng giảm thời gian chết nhiều hơn so với nguyên nhân
• Phân tách dữ liệu và khối lượng gốc, thậm chí có thể đặt cơ sở dữ liệu vào khối lượng riêng của chúng và chụp nhanh trước khi cập nhật nếu cần thiết
• Sử dụng nhật ký bin để ở trạng thái 'nóng' nhất có thể - tải tệp này (đã nén) lên S3
• Đảm bảo bạn thực sự lấy dữ liệu ra khỏi thể hiện (ngay cả khi dữ liệu còn nguyên vẹn trên một ổ EBS, thì chính khối lượng đó có thể tạm thời không thể truy cập được).

Đề nghị đọc:

• Trang của Amazon trên EBS
• Câu hỏi thường gặp về EBS

(Tôi tin rằng tôi đã viết quá nhiều, nhưng không nói đủ - nhưng hy vọng bạn tìm thấy một cái gì đó đáng để đọc).

Có thể chụp nhanh một khối EBS trực tiếp , tuy nhiên bạn phải cẩn thận để đảm bảo rằng hệ thống tập tin ở trạng thái nhất quán và sau đó bị đóng băng trong khi ảnh chụp nhanh được bắt đầu. Không phải tất cả các hệ thống tập tin đều cho phép điều này, mặc dù điều đó là hoàn toàn có thể và là nền tảng của giải pháp sao lưu riêng của chúng tôi.

Ảnh chụp nhanh EBS cũng khá rẻ vì chúng chỉ tính phí cho dữ liệu thay đổi và phí dữ liệu rất hợp lý trong và ngoài. Mặc dù vậy, hãy nhớ rằng điều này dựa trên thay đổi cấp độ khối, do đó có thể thay đổi khá nhanh. Điều này cũng đúng giữa các ảnh chụp nhanh, chỉ có dữ liệu thay đổi giữa các ảnh chụp nhanh được tính phí. Để cung cấp cho bạn ý tưởng về chi phí, chúng tôi phải trả <$ 10 mỗi tháng cho lưu trữ ảnh chụp nhanh và chúng tôi chụp ảnh nhanh hàng ngày, giữ 7 tờ nhật báo cuối cùng và các ảnh chụp nhanh hàng tháng và chúng tôi có 2 máy chủ theo sơ đồ này (~ 20 ảnh chụp nhanh, Ổ cứng 20 GB).

Làm thế nào về một giải pháp sao lưu rẻ tiền rẻ tiền như Zmanda Cloud Backup? Chúng tôi sử dụng nó để sao lưu khoảng 6 máy chủ và 1 Máy chủ SQL và chỉ khoảng $ 10 mỗi tháng. Bạn có thể mã hóa dữ liệu của mình bằng một chứng chỉ tự ký và họ sử dụng s3 để lưu trữ dữ liệu (vì vậy không có phí chuyển dữ liệu nếu bạn đang sao lưu từ EC2).