Xây dựng chính sách chuyển đổi dự phòng đám mây

Tạo chính sách chuyển đổi dự phòng với những bài toán ứng dụng đặc trưng-đám mây để mô tả chi tiết các thành phần và nhiệm vụ

Trong vài năm gần đây, hầu hết các tổ chức và các cơ quan hoặc đã dịch chuyển một phần dữ liệu của mình lên đám mây, sẽ đang trong quá trình chuyển đổi dữ liệu hoặc sẽ đi sâu vào việc lập kế hoạch một số cách sử dụng đám mây — hai mối quan tâm chính của họ sẽ vẫn là độ tin cậy và bảo mật. Về mặt độ tin cậy, các tổ chức vẫn cần phải có ít nhất là 99,5% thời gian vận hành. Thật không may, nhiều tổ chức vẫn sử dụng một cách phản ứng "đối phó" khi có lỗi thay vì chọn dùng các bước đi chủ động khôn khéo hơn: Tạo ra một chính sách chuyển đổi dự phòng đám mây với nhiều bài toán ứng dụng đặc trưng-đám mây, mỗi bài toán đều dự tính chi tiết các thành phần và nhiệm vụ. Tác giả bài này cung cấp một lộ trình để tạo một chính sách như vậy và minh họa những bài toán ứng dụng và các kịch bản chính sách về có thể thực hiện những hành động chủ động nào khi xảy ra các lỗi.

Judith M. Myerson, Kỹ sư hệ thống và kiến trúc sư

Judith M. Myerson là một kiến trúc sư và kỹ sư hệ thống. Cô quan tâm nhiều đến các lĩnh vực hệ thống toàn doanh nghiệp, các công nghệ phần mềm trung gian, các công nghệ cơ sở dữ liệu, điện toán đám mây, các chính sách ngưỡng, các ngành nghề, quản lý mạng, bảo mật, các công nghệ RFID, quản lý trình bày và quản lý dự án.


Cấp độ đóng góp cho developerWorks của
        tác giả

29 03 2013

Mục tiêu của chính sách chuyển đổi dự phòng đám mây là bảo đảm dịch vụ đám mây luôn sẵn sàng ít nhất là 99,5% thời gian. Nó nên tập trung vào cách có thể chuyển đổi một ứng dụng Phần mềm là một Dịch vụ (SaaS), Nền tảng là một Dịch vụ (PaaS) hoặc các máy tính ảo Cơ sở hạ tầng là một Dịch vụ (IaaS) đang chạy trong một dịch vụ đám mây từ một trung tâm dữ liệu có lỗi sang một trung tâm dữ liệu khỏe mạnh để cung cấp dịch vụ hầu như liên tục cho các khách hàng đám mây.

Những người dùng đám mây muốn tránh lỗi gây nên thảm họa của một dịch vụ đám mây là việc ngắt mạng đã xảy ra với Vùng trung tâm dữ liệu (Virginia Bắc) Hoa Kỳ của Amazon ít nhất hai lần:

  • Vào năm 2007, Dịch vụ Amazon Elastic Compute Cloud (EC2 – Đám mây điện toán co giãn của Amazon) đã bị ảnh hưởng.
  • Vào năm 2011, giải pháp PaaS, EC2 và Dịch vụ cơ sở dữ liệu quan hệ của Điện toán đám mây của Amazon bị ảnh hưởng.

Nhưng hai vùng trung tâm dữ liệu khác của Amazon tại Hoa Kỳ vẫn tiếp tục chạy trong tình trạng rất khỏe mạnh.

Tại vùng Virginia Bắc, dịch vụ EC2 của Amazon đã tự động tạo ra các bản sao lưu của chính các khối lượng lưu trữ thường dùng dẫn đến làm tràn dung lượng lưu trữ. Khi các việc sao lưu tự động đã cố gắng tự lưu trữ vượt quá giới hạn dung lượng lưu trữ tối đa của mình, thì việc ngắt mạng chắc chắn xảy ra. Mạng này đã chẳng còn chỗ nào để lưu trữ thêm các bản sao lưu được nữa.

Việc ngắt mạng kiểu này có thể làm cho các khách hàng mất hàng ngàn giờ dữ liệu. Bài này giới thiệu cho bạn cách tránh các kiểu thiệt hại như vậy. Nó mô tả chính sách chuyển đổi dự phòng đám mây, những bài toán ứng dụng và các kịch bản đặc trưng-đám mây để tạm dừng lỗi, sửa lỗi, phục hồi hệ thống và thông báo cho các khách hàng.

Bài toán ứng dụng đặc trưng-SaaS

Dưới đây là các ví dụ về các thành phần và nhiệm vụ nào cần được đưa vào một bài toán ứng dụng đặc trưng-SaaS cho một chính sách chuyển đổi dự phòng đám mây chủ động.

Các thành phần

Do một người dùng SaaS chỉ có quyền điều khiển hạn chế nên bài toán ứng dụng đặc trưng-SaaS gồm có ít nhất ba thành phần sau:

  • Quyền điều khiển của người dùng.
  • Giấy phép người dùng.
  • Một kế hoạch chuyển đổi dự phòng.

Một người dùng SaaS có quyền điều khiển duy nhất là truy cập các ứng dụng SaaS để thực hiện các chức năng nghiệp vụ. Thành phần giấy phép cho người dùng, theo thỏa thuận với nhà cung cấp, nên quy định số lượng tối đa về:

  • Các ứng dụng SaaS cần truy cập.
  • Những người dùng đồng thời truy cập một ứng dụng.
  • Các yêu cầu được cấp cho mỗi người dùng.

Thành phần giấy phép người dùng nên chỉ rõ các kiểu ứng dụng SaaS mà những người dùng được phép truy cập, chẳng hạn như tài chính, quản lý dự án, các quan hệ khách hàng, quản lý bán lẻ và thậm chí cả máy quét lỗ hổng bảo mật với Rational AppScan của IBM.

Thành phần kế hoạch chuyển đổi dự phòng nên nói rõ các cá thể ứng dụng SaaS được đưa ra để cho phép chuyển đổi dự phòng từ một trung tâm lưu trữ trên máy chủ này sang một trung tâm lưu trữ trên máy chủ khác. Thành phần này sẽ cho biết nhà cung cấp dịch vụ cung cấp cả hai thỏa thuận về các dịch vụ sao lưu dự phòng và thỏa thuận về mức dịch vụ (SLA) và tuân thủ các luật về tính riêng tư dữ liệu chẳng hạn như Đạo luật về tính riêng tư và Đạo luật về các tài liệu điện tử (Federal Privacy Act and Electronic Documents Act).

Các nhiệm vụ

Ít nhất những người dùng SaaS nên được phép:

  • Truy cập ứng dụng SaaS lên đến số lượng truy cập tối đa cho mỗi người dùng.
  • Cập nhật các bản ghi dựa trên các vai trò mà những người dùng được cấp.
  • Nhận các cảnh báo bảo mật.

Chỉ có các nhà cung cấp mới có thể:

  • Mua một giấy phép nâng cấp phần mềm.
  • Quản lý các bản vá lỗi cho các ứng dụng SaaS.
  • Truy cập các ứng dụng hệ thống và các máy ảo.
  • Truy cập Cơ sở hạ tầng điện toán truyền thống bên dưới các máy ảo.

Khi một ứng dụng SaaS có lỗi, nhà cung cấp nên chỉ rõ cách mình có thể chuyển đổi dự phòng ứng dụng SaaS đó từ trung tâm dữ liệu có lỗi sang một trung tâm dữ liệu khỏe mạnh trong thời gian ngắn nhất có thể (với các khoảng thời gian không quá năm phút) và cách mình có thể phục hồi ứng dụng đó sau khi sửa các lỗi.

Hãy xem xét một kịch bản SaaS có lỗi để minh họa kiến thức này.


Một kịch bản SaaS có lỗi

Các ứng dụng CRM tại một công ty đã được di trú thành công như các ứng dụng SaaS tới một nhà cung cấp bên ngoài đang lưu trữ trên máy chủ một môi trường nhiều bên thuê trong các vùng trung tâm dữ liệu tại Hoa Kỳ. Khi có một sự cố mạng ở một trung tâm dữ liệu làm ngắt hệ thống một vài ngày — do các việc sao lưu dự phòng dữ liệu lưu trữ tự động làm tràn tất cả các dung lượng lưu trữ và chẳng để lại chỗ nào trên mạng để lưu trữ 200 triệu giao dịch từ tất cả các nơi trên thế giới — dẫn đến một sự bùng phát các khiếu nại tới tấp dồn đến (như bạn đã dự kiến):

  • Nhân viên bán hàng la ó.
  • Điện thoại tại các trung tâm trợ giúp cuộc gọi đã liên tục đổ chuông trong nhiều ngày.
  • Nhà cung cấp than phiền (khi người ta phát hiện ra rằng các ứng dụng CRM SaaS chưa thể hoạt động trong vòng hai phút sau khi có lỗi, như đã được bảo đảm trong một SLA thỏa thuận với những người dùng SaaS).

Cuống lên vì các giải pháp nhanh, nhà cung cấp đưa ra một thông báo trên trang web của mình, "Xin vui lòng chờ ... chúng ta sẽ sớm có hệ thống". Điều này không phải là quá muộn.

Phải mất một vài ngày để nhà cung cấp đưa các ứng dụng SaaS làm việc trở lại. Nhà cung cấp không thể tạo ra việc chuyển đổi dự phòng có hiệu quả. Dưới đây là các hành động chủ động để nhà cung cấp có thể dùng để tạm dừng lỗi, sửa các lỗi, phục hồi hệ thống và thông báo cho các khách hàng.

Tạm dừng lỗi

Để tạm dừng lỗi, hãy lập kế hoạch trước bằng cách chuẩn bị cho các ứng dụng SaaS như là các cá thể dùng để chuyển đổi dự phòng tự động. Cần đưa ra SLA như đã thỏa thuận giữa các thuê bao SaaS và nhà cung cấp. Khi hiệu năng giảm nhanh xuống dưới mức sẵn sàng dịch vụ đã cam kết (99,9%), một cảnh báo sẽ được gửi đến nhà cung cấp. Có thể đưa hiệu năng đã ở dưới mức sẵn sàng trở lại mức cam kết hầu như tức thời tùy thuộc vào lưu lượng trên mạng.

Trong khi đó, các khách hàng SaaS được thông báo rằng dịch vụ vẫn được tiếp tục tại một trung tâm dữ liệu khác trong khi nhà cung cấp dịch vụ đang sửa chữa các lỗi. Nhà cung cấp sẽ báo cho các khách hàng biết khi dịch vụ được phục hồi tại trung tâm dữ liệu ban đầu.

(Lưu ý rằng có một yếu tố rõ ràng về thông báo trong tất cả các hành động chủ động được mô tả trong các chính sách này: Việc để cho các bên liên quan biết điều gì đang diễn ra trong các hoạt động của bạn thường có thể khiến cho bạn phải trả giá bằng nhiều thời gian để sửa chữa một lỗi; nhưng việc không cho các khách hàng biết về một tình huống hợp pháp lại luôn đặt bạn vào thế bất lợi).

Sửa lỗi

Nhà cung cấp có thể lập kế hoạch trước cho việc chuyển đổi dự phòng và có một chính sách chuyển đổi dự phòng đám mây tại chỗ:

  • Cài đặt các cá thể của ứng dụng SaaS để cho phép chuyển đổi dự phòng từ một trung tâm dữ liệu này sang một trung tâm dữ liệu khác.
  • Định kỳ kiểm tra để xác định xem các băng từ sao lưu có đang làm việc đúng không và không có các lỗi nào.
  • Kiểm tra để xem liệu phần mềm mạng có thể sửa các lỗi như đã dự kiến không.

Phục hồi hệ thống

Bước tiếp theo là bắt đầu phục hồi hệ thống tại trung tâm dữ liệu, nơi hệ thống đã bị ngắt mạng. Nhà cung cấp thiết lập một môi trường thử nghiệm để kiểm tra tính co giãn của hệ thống đã phục hồi để bảo đảm chuyển đổi dự phòng tương đối trôi chảy sang một trung tâm dữ liệu khác. Ví dụ, nhà cung cấp có thể ngẫu nhiên xóa tài nguyên và các dịch vụ và ghi nhận các kết quả.

Khi đã thử nghiệm xong, nhà cung cấp dịch vụ sao lưu dự phòng một bản sao của hệ thống đã phục hồi trước khi di chuyển nó sang một môi trường sản xuất.

Thông báo cho các khách hàng

Ngay khi phục hồi xong các ứng dụng SaaS trong trung tâm dữ liệu đã bị ngắt mạng, nhà cung cấp thông báo cho các khách hàng biết việc phục hồi đã xong và các điều khoản của SLA (tín dụng miễn phí, số tiền bồi hoàn, một cơ hội để chấm dứt thỏa thuận) sẽ được thực hiện.


Bài toán ứng dụng đặc trưng-PaaS

Các thành phần và các nhiệm vụ nào cần được đưa vào một bài toán ứng dụng đặc trưng-PaaS dùng cho một chính sách chuyển đổi dự phòng đám mây?

Các thành phần

Các nhà phát triển PaaS có nhiều quyền điều khiển hơn, do đó bài toán ứng dụng đặc trưng-PaaS cần có ít nhất nhiều hơn một thành phần so với bài toán ứng dụng SaaS — khả năng với các ứng dụng của nhà phát triển (các thành phần dùng cho một nhà phát triển PaaS là quyền điều khiển của người dùng, giấy phép của nhà phát triển, phát triển ứng dụng (không có sẵn với người dùng SaaS) và một kế hoạch chuyển đổi dự phòng.

Một nhà phát triển PaaS kiểm soát sự phát triển của các ứng dụng SaaS và tất cả các ứng dụng đã tìm thấy trong toàn bộ vòng đời nghiệp vụ; ví dụ, các bảng tính, các bộ xử lý văn bản và các bản sao lưu dự phòng.

Thành phần giấy phép của nhà phát triển như đã thỏa thuận với nhà cung cấp dịch vụ nên chỉ rõ số lượng tối đa về:

  • Các ứng dụng để phát triển.
  • Số lượng các nhà phát triển ứng dụng đồng thời được phép.
  • Số lượng những người dùng SaaS được phép truy cập các ứng dụng trên PaaS.

Thành phần phát triển ứng dụng nên chỉ rõ các kiểu ứng dụng để phát triển, chẳng hạn như:

  • Các ứng dụng SaaS.
  • Các trang web.
  • Các ứng dụng CRM.
  • Các ứng dụng di động.
  • Các ứng dụng thanh toán và bảng lương.
  • Các ứng dụng Nền tảng phân phối dịch vụ - Service Delivery Platform (như truyền hình di động).
  • Các ứng dụng quản lý phân phối nội dung.

Một thành phần kế hoạch chuyển đổi dự phòng nên chỉ rõ các cá thể ứng dụng PaaS được đưa ra để cho phép chuyển đổi dự phòng từ một trung tâm lưu trữ trên máy chủ này sang một trung tâm lưu trữ trên máy chủ khác. Thành phần này chỉ rõ liệu một nhà phát triển PaaS sẽ có thể sử dụng ứng dụng chuyển đổi dự phòng riêng của mình hay của nhà cung cấp hay không và nhà phát triển có hay không có khả năng sử dụng các công cụ của bên thứ ba cho các nhiệm vụ như việc cân bằng tải chẳng hạn. Kế hoạch này cũng nên cho biết liệu nhà cung cấp dịch vụ có cung cấp cả các dịch vụ sao lưu dự phòng lẫn các SLA hay không và liệu kế hoạch này có tuân thủ các luật về tính riêng tư dữ liệu không.

Các nhiệm vụ

Các nhà phát triển PaaS được phép:

  • Xây dựng, triển khai và chạy các ứng dụng.
  • Quản lý các bản vá lỗi và các bản nâng cấp.
  • Quyết định những người dùng SaaS nào có thể truy cập các ứng dụng SaaS cùng tồn tại trên PaaS.
  • Tùy chỉnh linh hoạt các nền tảng của họ để đáp ứng lại các điều kiện thị trường cục bộ.

Họ cũng được phép:

  • Quét các ứng dụng để tìm các lỗ hổng bảo mật.
  • Cấu hình các tường lửa của ứng dụng.
  • Xây dựng và giám sát các cảnh báo bảo mật.
  • Thực hiện các hoạt động sao lưu dự phòng.

Ít nhất chỉ nhà cung cấp mới có thể:

  • Chạy các ứng dụng hệ thống.
  • Chạy các máy ảo.
  • Truy cập Cơ sở hạ tầng điện toán truyền thống bên dưới các máy ảo.

Hãy xem xét một kịch bản PaaS có lỗi để minh họa kiến thức này.


Một kịch bản PaaS có lỗi

Một ứng dụng "tối ưu hóa tài nguyên" của nhà phát triển PaaS có lỗi. Lỗi này làm cho nền tảng này và các nền tảng PaaS khác đã lưu trên máy chủ của cùng một nhà cung cấp hoàn toàn đóng lại. Lỗi này có thể đã bị gây ra do lỗi để tạo ra các cá thể của dịch vụ sao chép để có thể vượt qua các lỗi máy chủ. Thật không may, ứng dụng "tối ưu hóa tài nguyên" đã không nhận biết được các lỗi, cũng không thực hiện thời gian chờ ngắn và chạy lại nhanh chóng.

Nhà cung cấp có thể sử dụng những hành động chủ động dưới đây bằng cách thực hiện các điều khoản của bài toán ứng dụng đặc trưng PaaS đã thỏa thuận với nhà cung cấp về tạm dừng lỗi, sửa các lỗi, phục hồi hệ thống và thông báo cho các khách hàng.

Tạm dừng lỗi

Để tạm dừng lỗi, nhà phát triển PaaS xây dựng các dịch vụ đơn giản gồm có một máy chủ duy nhất thay vì nhiều máy chủ phụ thuộc. Điều này cho phép nhà phát triển tạo ra các cá thể dịch vụ sao chép có thể vượt qua được các lỗi máy chủ.

Sửa lỗi

Khi xuất hiện lỗi, phần mềm của nhà phát triển nên nhanh chóng nhận biết các lỗi đó và bắt đầu quá trình chuyển đổi dự phòng.

Hãy giả sử nếu nhà phát triển có một ứng dụng thanh toán gồm có các thành phần logic nghiệp vụ ... A, B, và C ... anh ta có thể soạn một nhóm dịch vụ như sau:

(A1, B1, C1), (A2, B2, C2) ... (An, Bn, Cn)

Where n is the number of component type representing the number of a 
service group category

        for service category 1, 
                A1 is the logic to find service code
                B1 is the logic to insert service category into the bill
                C1 is the logic to check the accuracy of zip codes
				
        for service category 2, 
                A2 is the logic to find service code
                B2 is the logic to insert service category into the bill
                C2 is the logic to check the accuracy of zip codes
				
        for service category n, 
                An is the logic to find service code
                Bn is the logic to insert service category into the bill
                Cn is the logic to check the accuracy of zip codes

Nếu một máy ảo đang chạy PaaS bị lỗi, lỗi này dẫn đến việc mất toàn bộ nhóm hệ thống. Điều này có nghĩa là nếu thành phần A1 bị lỗi trong một nhóm hệ thống, thì hai thành phần khác, B1C1, cũng bị lỗi. Nếu có nhiều hơn một nhóm dịch vụ bị lỗi, thì toàn bộ hệ thống bị lỗi.

Để sửa lỗi này, nhà phát triển phân tích các thành phần thành các nhóm độc lập như sau:

(A1, A2,...An ), (B1, B2...Bn ), (C1, C2, ...Cn)

Nhờ đó anh ta có thể tạo ra nhiều bản sao dịch vụ dự phòng tại các trung tâm dữ liệu khỏe mạnh. Điều này có nghĩa là nếu thành phần A1 bị hỏng hoặc chạy chậm lại, thì tất cả các thành phần A2... An khác trong cùng một nhóm độc lập không bị lỗi. Nhóm độc lập thứ hai của các thành phần B1, B2...Bn và nhóm thứ ba của các thành phần C1, C2, ...Cn không bị lỗi.

Nhà phát triển sử dụng các thời gian chờ và chạy lại nhanh chóng của các dịch vụ chạy chậm trong khi chuyển đổi dự phòng cho tất cả các nhóm dịch vụ độc lập của các ứng dụng thanh toán đang được tiến hành. Nhà phát triển cần xác định khi nào tạm dừng các thời gian chờ và chạy lại để tránh tình trạng treo hệ thống do việc tiêu dùng tất cả tài nguyên để phục vụ các dịch vụ bị lỗi hay chạy chậm.

Phục hồi hệ thống

Bước tiếp theo là bắt đầu phục hồi nền tảng PaaS tại trung tâm dữ liệu nơi hệ thống đã bị ngắt mạng. Trong một môi trường thử nghiệm, nhà cung cấp ngẫu nhiên tạm dừng tài nguyên và các dịch vụ bên dưới PaaS. Nhà phát triển thử nghiệm các ứng dụng theo các điều kiện khác nhau để kiểm tra khả năng phục hồi của PaaS. Khi thử nghiệm xong, nhà cung cấp sao lưu hệ thống đã phục hồi trước khi chuyển nó sang một môi trường sản xuất.

Thông báo cho các khách hàng

Ngay khi các ứng dụng PaaS đang chạy ở trung tâm dữ liệu đã được khôi phục, nhà cung cấp thông báo cho các nhà phát triển PaaS về hệ thống đã phục hồi và các điều khoản của SLA được thực hiện.


Bài toán ứng dụng đặc trưng-IaaS

Cuối cùng, các thành phần và các nhiệm vụ nào cần được đưa vào một bài toán ứng dụng đặc trưng-IaaS cho một chính sách chuyển đổi dự phòng đám mây?

Các thành phần

Do IaaS là nền tảng của mức PaaS, nên bài toán ứng dụng đặc trưng-IaaS cần chứa một tập hợp các thành phần khác nhau. Bên cạnh quyền điều khiển của người dùng, giấy phép doanh nghiệp và một kế hoạch chuyển đổi dự phòng, bạn sẽ thấy có một thành phần dùng cho các máy ảo.

Một chuyên gia IaaS kiểm soát các máy ảo; còn các nhà phát triển PaaS và những người dùng SaaS thì không.

Giấy phép doanh nghiệp nên chỉ rõ số lượng tối đa về:

  • Các máy ảo để phát triển, chạy và bảo trì.
  • Các chuyên gia IaaS đồng thời truy cập các máy ảo.
  • Các nhà phát triển PaaS để làm việc trên đỉnh của các máy ảo IaaS.

Một kế hoạch chuyển đổi dự phòng nên cho phép chuyển đổi dự phòng các máy ảo IaaS từ một trung tâm lưu trữ trên máy chủ này sang một trung tâm lưu trữ trên máy chủ khác. Kế hoạch này sẽ cho phép các chuyên gia mạng và cơ sở hạ tầng IaaS làm việc với các nhà phát triển PaaS để thiết lập các máy ảo chuyển đổi dự phòng.

Các nhiệm vụ

Chuyên gia IaaS có thể:

  • Xây dựng, quản lý và truy cập các máy ảo.
  • Ủy quyền cho các nhà phát triển PaaS phát triển các ứng dụng trên các máy ảo.
  • Sử dụng các công cụ của bên thứ ba để làm tăng hiệu năng (ví dụ, một trình cân bằng tải) và bảo vệ dữ liệu hệ thống.
  • Quét các máy ảo để tìm các lỗ hổng bảo mật.

Các chuyên gia này cũng được phép:

  • Cấu hình các tường lửa máy ảo.
  • Xây dựng và giám sát các cảnh báo bảo mật.
  • Sao lưu dự phòng các máy ảo.

Chỉ có nhà cung cấp mới có thể truy cập vào cơ sở hạ tầng của tài nguyên máy tính truyền thống bên dưới các máy ảo. Còn chuyên gia IaaS thì không thể.

Hãy xem xét một kịch bản IaaS có lỗi để minh họa kiến thức này.


Một kịch bản IaaS có lỗi

Các máy ảo bị lỗi do thiếu tài nguyên bổ sung cần thiết để tiêu dùng tại các thời điểm có lưu lượng Vào/ra cao. Nói cách khác, không có cá thể máy ảo nào tồn tại để cho phép chuyển đổi dự phòng sang một trung tâm dữ liệu khỏe mạnh.

Nhà cung cấp có thể dùng những hành động chủ động sau đây.

Tạm dừng lỗi

Để tạm dừng lỗi, hãy lập kế hoạch về lượng tài nguyên cần thiết để chạy các máy ảo tại các thời điểm có lưu lượng Vào/ra cao. Kế hoạch này có thể được thực hiện thông qua các chính sách lập kế hoạch dung lượng và các chính sách ngưỡng hiệu năng, chẳng hạn. (Có các bài viết khác chi tiết hơn trong phần Tài nguyên đề cập đến các chính sách ngưỡng và lập kế hoạch dung lượng).

Sửa lỗi

Để sửa lỗi đó, hãy thiết lập các chính sách ngưỡng hiệu năng để xác định khi nào cần cung cấp các máy ảo cần thiết trong các thời điểm có lưu lượng Vào/ra cao và cách bảo đảm đáp ứng tất cả các điểm kích hoạt dịch vụ. Hãy chắc chắn đưa ra các cá thể máy ảo tại các trung tâm dữ liệu do máy chủ kiểm soát.

Ngoài ra, khi xảy ra lỗi, hãy lập kế hoạch để nhanh chóng nhận biết lỗi và để nhà cung cấp chuyển đổi các cá thể máy ảo dựa trên IaaS sang một trung tâm dữ liệu khác.

Phục hồi hệ thống

Bước tiếp theo là bắt đầu phục hồi nền tảng IaaS tại trung tâm dữ liệu, nơi hệ thống đã bị ngắt mạng. Trong một môi trường thử nghiệm, nhà cung cấp ngẫu nhiên có thể tạm dừng các tài nguyên và các dịch vụ bên dưới IaaS. Sau khi thử nghiệm xong, nhà cung cấp dịch vụ sao lưu hệ thống đã phục hồi trước khi chuyển nó sang một môi trường sản xuất.

Thông báo cho khách hàng

Ngay khi các máy ảo đang chạy ở trung tâm dữ liệu đã phục hồi, nhà cung cấp thông báo cho các chuyên gia IaaS về sự phục hồi hoàn toàn của các máy ảo tại trung tâm dữ liệu.


Kết luận

Bộ khung của một chính sách chuyển đổi dự phòng đám mây có hiệu quả đòi hỏi phải hoạch định chính sách chủ động để:

  • Xác định lý do xảy ra các lỗi đám mây.
  • Nhận biết các lỗi đó.
  • Chuẩn bị những bài toán ứng dụng đặc trưng-đám mây theo chính sách để chủ động đối phó với các thay đổi là nguyên nhân gây ra các lỗi đó.

Nhóm các nhà phát triển, những người dùng và các nhà cung cấp của bạn cần làm việc với nhau để xây dựng chính sách và các bài toán ứng dụng. Nhóm làm việc sẽ tìm ra cách giải quyết các vấn đề về việc nên đưa vào các yếu tố, các thành phần và các nhiệm vụ nào để làm cho công việc xây dựng chính sách của họ trở nên dễ dàng hơn nhiều.

Trong bài này, tôi đã trình bày các thành phần và các nhiệm vụ cơ bản cần được xem xét như là một phần của một chính sách chuyển đổi dự phòng theo từng mô hình điện toán đám mây — SaaS, PaaS và IaaS. Tôi cũng đã cung cấp các gợi ý về việc làm thế nào để nhà cung cấp có thể tiến hành tạm dừng lỗi, sửa lỗi, phục hồi hệ thống và tất nhiên, thông báo cho khách hàng, đối với từng mô hình.

Các bài viết khác (trong phần Tài nguyên) đi sâu hơn vào việc định nghĩa các yếu tố chính sách về mục đích, phạm vi, nền tảng, các hành động và những hạn chế để giúp bạn phác thảo các chính sách điện toán đám mây để giải quyết các thủ tục kích hoạt ngưỡng, việc cân bằng tải công việc, bảo mật chung, truy cập di động, di trú ứng dụng, quản lý rủi ro dịch vụ, các số liệu đo hiệu năng và nhiều hơn nữa. Trong tất cả các hướng dẫn chính sách mà tôi đã cung cấp, độ tin cậy và bảo mật luôn được coi là các thành phần cơ bản then chốt.

Tài nguyên

Học tập

Lấy sản phẩm và công nghệ

Thảo luận

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Cloud computing, SOA và dịch vụ Web
ArticleID=863222
ArticleTitle=Xây dựng chính sách chuyển đổi dự phòng đám mây
publish-date=03292013