Lợi ích của EBS so với cửa hàng cá thể (và ngược lại) [đã đóng]

Tôi không rõ những lợi ích tôi nhận được từ EBS so với cửa hàng cá thể cho các phiên bản của tôi trên Amazon EC2. Nếu bất cứ điều gì, có vẻ như EBS hữu ích hơn nhiều (dừng lại, bắt đầu, kiên trì + tốc độ tốt hơn) với sự khác biệt tương đối nhỏ về chi phí ...? Ngoài ra, có bất kỳ số liệu nào về việc liệu nhiều người đang sử dụng EBS bây giờ có sẵn hay không, vì nó vẫn còn tương đối mới?

Điểm mấu chốt là bạn hầu như luôn luôn nên sử dụng các phiên bản được hỗ trợ EBS.

Đây là lý do tại sao

• Các trường hợp được hỗ trợ EBS có thể được đặt để chúng không thể (vô tình) bị chấm dứt thông qua API.
• Các trường hợp được hỗ trợ EBS có thể bị dừng khi bạn không sử dụng chúng và tiếp tục lại khi bạn cần lại chúng (như tạm dừng PC ảo), ít nhất là với các kiểu sử dụng của tôi tiết kiệm nhiều tiền hơn tôi dành cho vài chục GB dung lượng EBS.
• Các phiên bản được hỗ trợ của EBS không bị mất bộ nhớ cá nhân khi chúng gặp sự cố (không phải là yêu cầu cho tất cả người dùng, nhưng giúp phục hồi nhanh hơn nhiều)
• Bạn có thể tự động thay đổi kích thước lưu trữ đối tượng EBS.
• Bạn có thể chuyển bộ lưu trữ đối tượng EBS sang một phiên bản hoàn toàn mới (hữu ích nếu phần cứng tại Amazon bạn đang chạy bị lỗi hoặc chết, điều này thỉnh thoảng xảy ra)
• Sẽ nhanh hơn để khởi chạy một phiên bản được hỗ trợ EBS vì hình ảnh không phải được tìm nạp từ S3.
• Nếu phần cứng, phiên bản được hỗ trợ EBS của bạn được lên lịch để bảo trì , việc dừng và bắt đầu phiên bản đó sẽ tự động chuyển sang phần cứng mới. Tôi cũng có thể di chuyển một cá thể được EBS hỗ trợ trên phần cứng bị lỗi bằng cách buộc dừng thể hiện đó và khởi chạy lại nó (số dặm của bạn có thể thay đổi trên phần cứng bị lỗi).

Tôi là một người dùng nặng của Amazon và đã chuyển tất cả các phiên bản của tôi sang bộ nhớ được hỗ trợ EBS ngay khi công nghệ ra khỏi phiên bản beta. Tôi đã rất hài lòng với kết quả này.

EBS vẫn có thể thất bại - không phải là viên đạn bạc

Hãy nhớ rằng bất kỳ phần cơ sở hạ tầng dựa trên đám mây có thể thất bại bất cứ lúc nào. Lập kế hoạch cơ sở hạ tầng của bạn cho phù hợp. Mặc dù các phiên bản được hỗ trợ bởi EBS cung cấp mức độ bền nhất định so với các phiên bản lưu trữ phù du, nhưng chúng có thể và không thành công. Có AMI từ đó bạn có thể khởi chạy các phiên bản mới khi cần trong bất kỳ vùng khả dụng nào, sao lưu dữ liệu quan trọng của mình (ví dụ: cơ sở dữ liệu) và nếu ngân sách của bạn cho phép, hãy chạy nhiều phiên bản máy chủ để cân bằng tải và dự phòng (lý tưởng là trong nhiều vùng khả dụng ).

Khi không

Tại một số thời điểm, có thể rẻ hơn để đạt được IO nhanh hơn trên các phiên bản Instance Store. Đã có lúc nó chắc chắn là đúng. Bây giờ có nhiều tùy chọn để lưu trữ EBS, phục vụ cho nhiều nhu cầu. Các tùy chọn và giá cả của họ phát triển liên tục khi công nghệ thay đổi. Nếu bạn có một số lượng đáng kể các trường hợp thực sự dùng một lần (chúng không ảnh hưởng nhiều đến doanh nghiệp của bạn nếu chúng biến mất), hãy làm toán về chi phí so với hiệu suất. Các trường hợp được hỗ trợ bởi EBS cũng có thể chết bất cứ lúc nào, nhưng kinh nghiệm thực tế của tôi là EBS bền hơn.

99% thiết lập AWS của chúng tôi có thể tái chế. Vì vậy, đối với tôi nó không thực sự quan trọng nếu tôi chấm dứt một trường hợp - không có gì bị mất bao giờ. Ví dụ: ứng dụng của tôi được tự động triển khai trên một phiên bản từ SVN, nhật ký của chúng tôi được ghi vào một máy chủ nhật ký hệ thống trung tâm.

Lợi ích duy nhất của lưu trữ cá thể mà tôi thấy là tiết kiệm chi phí. Nếu không, các trường hợp được EBS hỗ trợ sẽ thắng. Eric đã đề cập đến tất cả những lợi thế.

[2012-07-16] Tôi sẽ diễn đạt câu trả lời này rất khác ngày hôm nay.

Tôi chưa có kinh nghiệm tốt với các trường hợp được EBS hỗ trợ trong năm vừa qua. Các thời gian ngừng hoạt động cuối cùng trên AWS cũng bị phá hủy khá nhiều EBS.

Tôi đoán rằng một dịch vụ như RDS cũng sử dụng một số loại EBS và dường như nó hoạt động với hầu hết các phần. Trong các trường hợp chúng tôi tự quản lý, chúng tôi đã loại bỏ EBS khi có thể.

Thoát khỏi phần mở rộng nơi chúng tôi đã chuyển một cụm cơ sở dữ liệu trở lại thành sắt (= phần cứng thực). Phần duy nhất còn lại trong cơ sở hạ tầng của chúng tôi là một máy chủ DB nơi chúng tôi ghép nhiều khối EBS vào RAID phần mềm và sao lưu hai lần một ngày. Bất cứ điều gì sẽ bị mất ở giữa các bản sao lưu, chúng ta có thể sống với.

EBS là một công nghệ hơi hoàn hảo vì về cơ bản nó là một khối lượng mạng: một khối lượng được gắn vào máy chủ của bạn từ xa. Tôi không phủ nhận công việc được thực hiện với nó - nó là một sản phẩm tuyệt vời vì về cơ bản lưu trữ liên tục không giới hạn chỉ là một cuộc gọi API. Nhưng nó hầu như không phù hợp với các tình huống trong đó hiệu suất I / O là chính.

Và ngoài cách thức hoạt động của bộ lưu trữ mạng, tất cả các mạng được chia sẻ trên các phiên bản EC2. Một cá thể càng nhỏ (ví dụ t1.micro, m1.small) thì càng tệ vì giao diện mạng của bạn trên hệ thống máy chủ thực tế được chia sẻ giữa nhiều VM (= thể hiện EC2 của bạn) chạy trên đầu máy.

Tất nhiên bạn càng lớn, tất nhiên nó càng tốt . Tốt hơn ở đây có nghĩa là trong lý do .

Khi cần sự kiên trì, tôi luôn khuyên mọi người nên sử dụng thứ gì đó như S3 để tập trung giữa các trường hợp. S3 là một dịch vụ rất ổn định. Sau đó tự động hóa thiết lập cá thể của bạn đến một điểm mà bạn có thể khởi động một máy chủ mới và nó sẽ sẵn sàng. Sau đó, không cần phải có bộ nhớ mạng tồn tại lâu hơn thể hiện.

Vì vậy, tất cả trong tất cả, tôi thấy không có lợi cho các trường hợp được hỗ trợ bởi EBS. Tôi thay vì thêm một phút để bootstrap, sau đó chạy với SPOF tiềm năng.

Chúng tôi thích cửa hàng cá thể. Nó buộc chúng tôi phải làm cho các cá thể của chúng tôi có thể tái chế hoàn toàn và chúng tôi có thể dễ dàng tự động hóa quá trình xây dựng một máy chủ từ đầu trên một AMI nhất định. Điều này cũng có nghĩa là chúng ta có thể dễ dàng trao đổi AMI. Ngoài ra, EBS vẫn có vấn đề về hiệu suất theo thời gian.

Eric đóng đinh khá nhiều. Chúng tôi ( Bitnami ) là nhà cung cấp AMI miễn phí phổ biến cho các ứng dụng và khung phát triển phổ biến (PHP, Joomla, Drupal, bạn hiểu ý). Tôi có thể nói với bạn rằng các AMI được EBS hỗ trợ phổ biến hơn đáng kể so với hỗ trợ S3. Nói chung, tôi nghĩ rằng các trường hợp được hỗ trợ bởi s3 được sử dụng cho các công việc phân tán, giới hạn thời gian (ví dụ: xử lý dữ liệu quy mô lớn) trong đó nếu một máy bị lỗi, thì một máy khác chỉ đơn giản là được tạo ra. AMIS được EBS hỗ trợ có xu hướng được sử dụng cho các tác vụ máy chủ 'truyền thống', chẳng hạn như máy chủ web hoặc cơ sở dữ liệu giữ trạng thái cục bộ và do đó yêu cầu dữ liệu phải có sẵn trong trường hợp bị sập.

Một khía cạnh tôi không thấy được đề cập là thực tế là bạn có thể chụp ảnh nhanh của một cá thể được hỗ trợ bởi EBS trong khi chạy, cho phép bạn có các bản sao lưu rất hiệu quả về cơ sở hạ tầng của mình (các ảnh chụp nhanh dựa trên khối và tăng dần)

Tôi đã có trải nghiệm chính xác giống như Eric ở vị trí cuối cùng của tôi. Bây giờ trong công việc mới của tôi, tôi đang trải qua quá trình tương tự tôi đã thực hiện ở công việc cuối cùng của mình ... xây dựng lại tất cả các AMI của họ cho các trường hợp được hỗ trợ EBS - và có thể là các máy 32 bit (rẻ hơn - nhưng không thể sử dụng cùng AMI trên 32 và 64 máy).

Các phiên bản được hỗ trợ của EBS khởi chạy đủ nhanh để bạn có thể bắt đầu sử dụng API Tự động hóa Amazon cho phép bạn sử dụng số liệu CloudWatch để kích hoạt khởi chạy các phiên bản bổ sung và đăng ký chúng vào ELB (Bộ cân bằng tải đàn hồi) và cũng tắt chúng khi tắt không còn cần thiết

Kiểu tự động động này là tất cả những gì AWS hướng tới - nơi tiết kiệm thực sự trong cơ sở hạ tầng CNTT có thể phát huy tác dụng. Rất nhiều điều không thể thực hiện tự động hóa đúng với các trường hợp được hỗ trợ "InstanceStore" cũ của s3.

Tôi mới bắt đầu sử dụng EC2 nên không phải là chuyên gia, nhưng tài liệu riêng của Amazon nói:

chúng tôi khuyên bạn nên sử dụng kho lưu trữ cục bộ cho dữ liệu tạm thời và, đối với dữ liệu yêu cầu mức độ bền cao hơn , chúng tôi khuyên bạn nên sử dụng khối lượng Amazon EBS hoặc sao lưu dữ liệu lên Amazon S3.

Nhấn mạnh mỏ.

Tôi thực hiện phân tích dữ liệu nhiều hơn so với lưu trữ web, vì vậy sự kiên trì không quan trọng với tôi như đối với một trang web. Với sự khác biệt do chính Amazon tạo ra, tôi sẽ không cho rằng EBS phù hợp với tất cả mọi người.

Tôi sẽ cố nhớ để cân nhắc lại sau khi tôi đã sử dụng cả hai.

EBS giống như đĩa ảo của VM:

• Bền bỉ, các phiên bản được hỗ trợ bởi EBS có thể được khởi động và dừng tự do (tiết kiệm tiền)
• Có thể được chụp nhanh tại bất kỳ thời điểm nào, để có được bản sao lưu tại thời điểm
• AMI có thể được tạo từ ảnh chụp nhanh EBS, vì vậy âm lượng EBS trở thành khuôn mẫu cho các hệ thống mới

Lưu trữ sơ thẩm là:

• Địa phương, vì vậy nói chung nhanh hơn
• Không nối mạng, trong các trường hợp thông thường, I / O EBS phải trả giá bằng băng thông mạng (trừ các trường hợp được tối ưu hóa EBS, có băng thông EBS riêng biệt)
• Có I / O giới hạn mỗi IOPS thứ hai. Thậm chí I / O được cung cấp tối đa ở mức vài nghìn IOPS
• Mong manh. Ngay khi dừng phiên bản, bạn sẽ mất tất cả mọi thứ trong bộ nhớ.

Đây là nơi để sử dụng từng:

• Sử dụng EBS cho phân vùng hệ điều hành sao lưu và lưu trữ vĩnh viễn (dữ liệu DB, nhật ký quan trọng, cấu hình ứng dụng)
• Sử dụng lưu trữ đối tượng cho dữ liệu trong quá trình, nhật ký không văn bản và trạng thái ứng dụng tạm thời. Ví dụ: lưu trữ sắp xếp bên ngoài, tempfiles, v.v.
• Lưu trữ sơ thẩm cũng có thể được sử dụng cho dữ liệu quan trọng về hiệu năng, khi có sự sao chép giữa các phiên bản (NoQuery DB, hệ thống hàng đợi / thông báo phân tán và DB có sao chép)
• Sử dụng S3 cho dữ liệu được chia sẻ giữa các hệ thống: tập dữ liệu đầu vào và kết quả được xử lý hoặc cho dữ liệu tĩnh được sử dụng bởi mỗi hệ thống khi được tán thành.
• Sử dụng AMI cho các máy chủ có thể khởi động, có thể khởi chạy

Hầu hết mọi người chọn sử dụng ví dụ được hỗ trợ EBS vì nó là trạng thái. Nó là để an toàn hơn bởi vì tất cả mọi thứ bạn đã chạy và cài đặt bên trong nó, sẽ tồn tại dừng / dừng hoặc bất kỳ trường hợp thất bại.

Cửa hàng sơ thẩm là không trạng thái, bạn mất nó với tất cả dữ liệu bên trong trong trường hợp có bất kỳ tình huống lỗi nào. Tuy nhiên, nó miễn phí và nhanh hơn vì âm lượng cá thể được gắn với máy chủ vật lý nơi VM đang chạy.

Đối với một người mới với tất cả điều này và nếu vô tình hạ cánh ở đây

Cho đến bây giờ, tất cả các AMI trong phần khởi động nhanh đều được hỗ trợ EBS

Ngoài ra có một lời giải thích tốt tại tài liệu chính thức về sự khác biệt giữa cửa hàng EBS và Instance

& hình ảnh này tổng hợp khá nhiều

Nếu bạn chạy nhiều phiên bản và chỉ định một dịch vụ theo lịch trình của AWS Instance là một trong những ưu tiên của bạn trong việc tránh các khoản phí bất ngờ , tôi khuyên bạn không nên sử dụng cửa hàng cá thể .

Như đã giải thích trên tài liệu của Tập EBS và câu trả lời từ j2d3 và Siddharth Sharma , cửa hàng cá thể có thể chạy bao lâu tùy thích, nhưng không thể dừng được . Có nghĩa là dịch vụ không thể được lên lịch bởi Khởi động / Dừng tự động hoặc Khôi phục sơ thẩm .

Hơn nữa, đối với loại lược đồ này cũng không có lợi ích gì khi sử dụng EBS Backed trên Elastic Beanstalk vì nó được thiết kế để đảm bảo rằng tất cả các tài nguyên bạn cần đều tiếp tục chạy . Nó sẽ luôn tự động khởi chạy lại bất kỳ dịch vụ nào mà bạn dừng. Xem xét tất cả phần còn lại , trong tổng số chi phí sử dụng VPC , EBS và ELB đã thêm vào EC2-Classic , EC2-VPC với ELB chủ yếu là lựa chọn tốt nhất trong đó không giống như trên EC2-Classic , một trường hợp dừng lại vẫn giữ được tính đàn hồi liên quan Các địa chỉ IPvà khối lượng EBS được lưu trữ tự động.

Để kết luận , lấy phần chính của câu hỏi của bạn:

có vẻ như EBS hữu ích hơn nhiều (dừng, bắt đầu, kiên trì + tốc độ tốt hơn) với sự khác biệt tương đối ít về chi phí ...?

Câu trả lời là có nhưng nếu trường hợp của bạn dựa trên EBS, nó có thể bị dừng. Nó sẽ vẫn còn trong tài khoản của bạn, bạn sẽ không bị tính phí cho nó . Bạn sẽ chỉ bị tính phí âm lượng nhưng EBS được tính phí hàng giờ . Bạn cũng có thể xem xét rằng trong số tất cả các loại khả dụng, bạn có thể linh hoạt Thay đổi kích thước Âm lượng EBS .

Bên cạnh những lợi ích đã được liệt kê bởi Eric , cũng cần lưu ý rằng về mặt chi phí S3 có thể hoặc không thể rẻ hơn EBS . Tôi đồng ý rằng nó tương đối ít khác biệt về chi phí nếu bạn cứ chạy cả hai loại thể hiện trong cùng một nền tảng và kiến ​​trúc của ứng dụng.

Tuy nhiên, nếu có một kịch bản để chạy ứng dụng trên một dịch vụ chi phí thấp hơn, hãy kéo tất cả các tác vụ chưa được xử lý và nhập chúng vào VPC / EBS thông qua một đường ống hoặc lambda trong một thời gian ngắn, nói rằng <1 giờ mỗi ngày, không thể thực hiện khi bạn sử dụng một cửa hàng cá thể , sau đó nó sẽ là một câu chuyện khác.