Mua giấy phép sử dụng các máy chủ DB2 9.7 phân tán trong môi trường sẵn sàng cao (HA)

Mua giấy phép sử dụng các máy chủ DB2 9.7 phân tán trong môi trường sẵn sàng cao (HA) Khách hàng chọn DB2 làm cơ sở dữ liệu ưa thích của họ bởi vì thời gian chứng tỏ giá trị (time to value) rất sớm của nó, khả năng mở rộng và tích hợp trong các môi trường khác nhau của nó, tính bền chắc của nó, và khả năng thời gian ngừng chạy tối thiểu (cả có kế hoạch lẫn ngoài kế hoạch). Trong bài viết này, chúng tôi tập trung vào các khía cạnh của tính sẵn sàng cao (HA) của DB2, không đề cập quá nhiều về chức năng (đã nhiều người viết về vấn đề này), mà về cấp quyền. Chúng tôi nghe rất nhiều câu hỏi về cấp phép cho DB2 trong môi trường có tính sẵn sàng cao, đó là các cấu hình được thiết kế để giải quyết các trường hợp ngừng chạy ngoài kế hoạch (và đôi khi cả các trường hợp có kế hoạch nữa). Thông thường, cái gây lúng túng nhất là do có sự khác nhau rất lớn trong việc các nhà cung cấp định giá bán các sản phẩm cơ sở dữ liệu của họ trong môi trường sẵn sàng cao. Một nguồn nhầm lẫn khác là từ các thuật ngữ được dùng khi thảo luận liên quan đến tính sẵn sàng cao. Ví dụ: thuật ngữ các cụm (clusters). Đôi khi ngành công nghiệp CNTT đề cập đến môi trường tính sẵn sàng cao là các cụm. Chúng tôi không thích tiếp tục sử dụng thuật ngữ này theo kiểu ấy nữa, vì nó đã trở thành cái gì đó quá tải trong thời gian gần đây, theo đó các cụm có thể nói đến việc tạo cụm để có khả năng mở rộng (giống như tính năng phân hoạch của cơ sở dữ liệu InfoSphere Warehouse (DPF) – tính năng này dựa trên DB2) hoặc tạo cụm để có tính sẵn sàng (Ví dụ: bằng cách sử dụng phần mềm phân cụm của hệ thống tự động Tivoli cho đa nền tảng (SA-MP), lần đầu tiên được đưa vào trong DB2 9 và sau đó được tích hợp sâu trong phiên bản DB2 9,5 cho nhóm các máy chủ), hoặc cả hai (như trường hợp cụm của DB2 pureScale, hoặc hệ thống phân tích thông minh của IBM). Mặc dù không thích thuật ngữ này, nhưng nó đã được sử dụng, vì thế đối với bài viết này, khi nói đến thuật ngữ cụm, chúng tôi muốn nói tạo cụm để cho tính sẵn sàng cao (trừ khi có ghi chú khác). Để đơn giản, chúng tôi khuyên bạn nên gắn thêm các chữ khả năng sẵn sàng cao hay khả năng mở rộng với thuật ngữ này khi thảo luận về các cụm với các đồng nghiệp hoặc khách hàng của bạn. Tất nhiên, một số giải pháp đề cập đến cả hai, cả khả năng mở rộng lẫn tính sẵn sàng cao bằng một cụm, vì thế, hãy đảm bảo rằng bạn luôn luôn truyền đạt những gì bạn đang cố gắng làm khi nói chuyện với đồng nghiệp của bạn. Một nguồn nhầm lẫn khác phát sinh từ các thuật ngữ sử dụng để mô tả các máy chủ hoạt động như máy chủ chuyển đổi dự phòng trong trường hợp có sự cố ngừng hoạt động. Ví dụ: Máy chủ này có thể được nói đến như là máy chủ dự phòng hoặc máy chủ thứ cấp (và nhiều tên gọi khác). Nếu bạn đã dính líu đến chúng trong khoảng thời gian đủ dài, thì nhiều khả năng là bạn đã gặp các thuật ngữ mô tả chức năng mà máy chủ này thực hiện. Các thuật ngữ như nhàn rỗi, đang hoạt động, lạnh, ấm, nóng, và thụ động tất cả đều được dùng trong các cuộc thảo luận về tính sẵn sàng. Phần lớn các tài liệu của Tập đoàn phần mềm của IBM (IBM SWG) sử dụng cách phân loại lạnh, ấm và nóng để mô tả các máy chủ ở chế độ chờ. Trước phiên bản DB2 9.5, mọi thứ trong lãnh địa của DB2 ("DB2-land") có hơi khác. Tuy nhiên, kể từ phiên bản DB2 9.5 (và các phiên bản sau này), cách phân loại khả năng sẵn sàng cao (HA) của DB2 và các điều khoản cấp giấy phép cho nó tuân thủ cách phân loại của IBM SWG và các điều khoản cấp giấy phép tương ứng phù hợp với chính sách định giá cho khả năng sẵn sàng cao. Ví dụ: Nếu bạn định cấu hình cho cụm khả năng sẵn sàng cao của DB2 9.1 HA bằng cách sử dụng PowerHA IBM AIX (còn gọi là Đa xử lý cụm khả năng sẵn sàng cao - High Availability Cluster Multiprocessing - HACMP), sao cho có một máy chủ nhàn rỗi (và trình quản lý cơ sở dữ liệu chưa khởi chạy), thì bạn cũng phải mua giấy phép sử dụng một phần máy chủ đó. Kể từ DB2 phiên bản 9.5 trở đi, bạn không phải trả một xu nào nữa! Tương tự như vậy, nếu bạn đã cài đặt DB2 phiên bản 9.1 tại một máy chủ không nối nguồn, bạn cũng đã phải mua phép sử dụng một phần cho máy chủ đó. Kể từ DB2 phiên bản 9.5 và các phiên bản sau đó bạn không phải mua mua giấy phép cho máy chủ DB2 không được nối nguồn. Chúng tôi đã cập nhật bài viết cho DB2 phiên bản 9.7 và bất kỳ thay đổi tạm thời nào như là kết quả của gói vá lỗi để giúp bạn phân loại các quy định cấp phép sử dụng cho khả năng sẵn sàng cao của DB2 và để bạn nắm được mọi thông tin. Lưu ý: Bài viết này cũng bàn về công nghệ pureScale DB2 được công bố lần đầu vào tháng 10 năm 2009. Phương tiện để phân phối DB2 pureScale là DB2 phiên bản 9.8; Tuy nhiên, lý do duy nhất để chạy DB2 phiên bản 9.8 là cho DB2 pureScale. Nói cách khác, nếu bạn đang chạy máy chủ DB2 phiên bản 9.7 và không có kế hoạch để sử dụng DB2 pureScale, bạn sẽ không phải chuyển sang DB2 phiên bản 9.8. Hình 1 mô tả rõ ràng cách phân loại khả năng sẵn sàng cao của DB2 phiên bản 9.7 và cung cấp một số ví dụ của từng loại cấu hình thuộc từng cách phân loại ấy. Hình 1. Một số gợi ý hữu ích cho cách phân loại khả năng sẵn sàng cao như là nóng, ấm, và lạnh của DB2 9.7 Bảng 1 cho thấy các thuật ngữ thường sử dụng nhất để mô tả môi trường sẵn sàng cao được ánh xạ với cách phân loại DB2 9.7 và các điều khoản cấp phép sử dụng. Bảng 1. Ánh xạ các thuật ngữ về tính sẵn sàng cao công nghiệp với các điều khoản cấp phép sử dụng DB2 9.7. Lạnh Ấm Nóng DB2 được cài đặt trên máy chủ nhằm mục đích dự phòng Phần mềm cơ sở dữ liệu được cài đặt trên máy chủ nhằm mục đích dự phòng Phần mềm cơ sở dữ liệu được cài đặt trên máy chủ nhằm mục đích dự phòng Cá thể cơ sở dữ liệu chưa được khởi chạy, và sẽ được khởi chạy chỉ khi chuyển đổi dự phòng xảy ra. Cá thể cơ sở dữ liệu được khởi chạy, và nó cũng có thể nhận được các thông tin cập nhật từ cơ sở dữ liệu chính cho mục đích khả năng sẵn sàng cao. Không có sự truy cập của người sử dụng cuối cùng nào vào cơ sở dữ liệu dự phòng này. Đồng thời máy chủ này duy trì kịch bản đối tác sẵn sàng cao của của nó, nó cũng phục vụ các ứng dụng khác như là máy chủ dữ liệu chính. Có sự truy cập của người dùng cuối cùng vào cơ sở dữ liệu dự phòng này ngay cả khi không có lỗi xảy ra. Thường được sử dụng trong kịch bản phân cụm khi việc phục hồi sau thảm họa với khả năng sẵn sàng cao (HADR) hoặc việc dịch chuyển bản ghi nhật ký không được triển khai và trình quản lý cơ sở dữ liệu không được chạy, chẳng hạn như cho PowerHA cho cụm AIX (trước đây là HACMP). Thường sử dụng trong HADR “vanilla” (không đọc ở chế độ chờ), trong Q-Replication, hoặc trong kịch bản dịch chuyển bản ghi nhật ký. Thường sử dụng trong HADR chuyển đổi dự phòng kép (sẽ nói thêm sau), trong HADR có đọc ở chế độ chờ, trong DB2 pureScale, và trong các kịch bản tạo bản đúp Bảng 1 bổ sung thêm một quy tắc ngón tay cái chung cho từng loại; tuy nhiên, sau khi đọc bài viết này, hy vọng là mọi việc sẽ rõ ràng. Rất đơn giản, bạn mua giấy phép sử dụng máy chủ DB2 trong một môi trường sẵn sàng cao như thế nào là tùy thuộc vào các câu trả lời của bạn cho một số câu hỏi then chốt sau đây: Bạn đã cài đặt phiên bản DB2 nào ? Đó có phải là các phiên bản DB2 Express-C, DB2 Express, DB2 Workgroup, DB2 Enterprise, hoặc DB2 Advanced Enterprise hay không? Ví dụ, một máy chủ DB2 Express với giấy phép SERVER (Được đưa vào khi DB2 9.7 trở thành phiên bản có sẵn) không có khái niệm nóng, ấm, hoặc lạnh cho máy chủ dự phòng (sẽ nói thêm sau). Bạn nên lưu ý là bạn không được cấp phép để định cấu hình cho DB2 Express-C miễn phí thành bất kỳ loại cấu hình tính sẵn sàng cao nào - Nếu bạn cần khả năng sẵn sàng cao thì bạn cần tối thiểu là DB2 Express. (Lưu ý rằng giấy phép FTL cho DB2 Express - C chỉ có sẵn trong DB2 phiên bản 9.5 và không còn có sẵn trong DB2 phiên bản 9.7 nữa. Bây giờ nó đã có sẵn dưới dạng giấy phép FTL cho DB2 Express: Giá vẫn như cũ với nhiều tính năng hơn !). (N.D.: FTL là viết tắt của “Fixed term license” – giấy phép ấn định thời hạn). Máy chủ dự phòng được sử dụng như thế nào khi lỗi không xảy ra? Ví dụ, có phải là nó được sử dụng như một máy chủ sản xuất cho giao dịch và truy vấn của DB2 hay không? Cá thể DB2 trên máy chủ này đã chạy chưa? Có lẽ cá thể đang thực hiện một số dạng công việc, nhưng chỉ để chủ yếu giúp phục hồi trong trường hợp lỗi, ví dụ: Trong kịch bản HADR. Có phải bạn đang quản lý cụm DB2 pureScale hay không? Rất đơn giản, máy chủ dự phòng đang làm gì khi tất cả mọi thứ đang chạy tốt, đó hầu như là tất cả những gì mà DB2 trên máy chủ đó cần phải được cấp giấy phép sử dụng. Bạn đã mua phép sử dụng máy chủ DB2, mà bạn muốn đảm bảo rằng nó sẵn sàng cao, như thế nào ? Ví dụ: Nếu bạn đã mua phép sử dụng máy chủ DB2 Express với giấy phép SERVER như đã được đưa vào trong DB2 9.7, thì bạn phải mua giấy phép SERVER bổ sung cho máy chủ dự phòng bất kể nó đang ở tình trạng hoạt động nào: nóng, ấm, hay lạnh. Nếu bạn mua giấy phép sử dụng máy chủ DB2 Express của bạn theo mô hình Người dùng được ủy quyền (Authorized User - AU), thì tức là bạn đã mua phép sử dụng máy chủ dự phòng trong trạng thái ấm cho 5 người dùng được ủy quyền và không cần mua phép sử dụng máy chủ dự phòng ở trang thái lạnh nữa. Nếu máy chủ DB2 Express của bạn được cấp phép sử dụng theo mô hình giá trị đơn vị trình xử lý Processor Value Unit (PVU) thì tức là bạn đã mua phép sử dụng máy chủ dự phòng ở trạng thái ấm cho 100 PVU (Bất kể máy chủ đang sử dụng kiến trúc bộ xử lý nào) và thậm chí cũng không cần mua phép sử dụng máy chủ dự phòng ở chế độ lạnh nữa. Nếu bạn đang tìm kiếm tổng quan về tất cả máy chủ DB2 9 phân tán và cách mua giấy phép sử dụng chúng, hãy tham khảo tài liệu "Ấn bản DB2 9.7 phân tán nào là phù hợp với bạn?". Để so sánh các tính năng, chức năng và lợi ích giữa các phiên bản máy chủ khác nhau của DB2, hãy đọc tài liệu "So sánh các máy chủ dữ liệu DB2 9.7 phân tán". Từ DB2 phiên bản 8.2 trở đi, đã có một số cải tiến về giấy phép sử dụng, các cải tiến này giảm đáng kể chi phí để có tính sẵn sàng cao liên kết với các máy chủ DB2 của bạn. Ví dụ, trong DB2 phiên bản 8.2, nếu bạn muốn mua giấy phép sử dụng DB2Workgroup với HADR, thi bạn phải mua gói Các tính năng sẵn sàng cao (High Availability Feature Pack) và mua giấy phép sử dụng gói tính năng này trên cả hai máy chủ. Với DB2 9, điều này đã thay đổi: bạn không còn phải mua giấy phép sử dụng gói tính năng này trên máy chủ dự phòng nữa. Trong DB2 phiên bản 9.5, IBM đã miễn phí gói các tính năng khả năng sẵn sàng cao cho các máy chủ DB2 Workgroup. Khá đơn giản, từ phiên bản này đến phiên bản khác, IBM đã giảm giá thành của môi trường khả năng sẵn sàng cao dựa trên DB2 của bạn nhờ có các thay đổi sau đây:  Khi một máy chủ đơn đang hoạt động như một máy chủ dự phòng ấm cho nhiều máy chủ sản xuất, bạn chỉ phải mua giấy phép sử dụng máy chủ dự phòng ấm (như DB2 8.2) một lần. Ví dụ: Nếu bạn đã mua giấy phép sử dụng máy chủ DB2 nóng cho số lượng không giới hạn người sử dụng, thì máy chủ dự phòng ấm sẽ yêu cầu 100 PVU. Nếu 5 máy chủ mức 400 PVU khác đang chạy DB2 Workgroup, và mỗi máy chủ được cấu hình trong cụm HADR để dự phòng cho chính máy chủ đó, bạn sẽ chỉ phải mua giấy phép sử dụng cho 2100 PVU (5 máy chủ x 400 + 100 PVU cho máy chủ dự phòng) chứ không phải là 2500 PVU [(5 máy chủ x 400 PVU) + (5 máy chủ x 100 PVU).  Bạn không cần phải mua giấy phép sử dụng các gói tính năng trên máy chủ đang hoạt động như máy chủ dự phòng ấm hoặc lạnh nữa (như trường hợp DB2 9). Ví dụ, nếu bạn đã mua giấy phép sử dụng gói Tính năng tối ưu hóa lưu trữ (Gói này cung cấp khả năng nén dữ liệu XML, các bảng, chỉ mục, các bảng tạm thời và nhiều loại khác) cho máy chủ DB2 Enterprise của bạn và đã định cấu cấu hình cơ sở dữ liệu để tham gia vào cụm HADR, thì bạn chỉ cần phải mua 100 PVU của DB2 Enterprise trên máy chủ dự phòng. Không cần mua giấy phép sử dụng thêm đối với gói Tính năng tối ưu hóa lưu trữ.  HADR được bao gồm trong DB2 Workgroup, không phải trả thêm phí (như DB2 9); nếu bạn quan sát xung quanh về tình hình cạnh tranh thì thấy không có nhà cung cấp nào khác cung cấp các chức năng tương tự (không có các hạn chế cho các công nghệ HADR trên DB2 Workgroup) cho bất kỳ máy chủ hướng SMB nào.  Bạn nhận được phần mềm phân cụm miễn phí cho hầu như bất kỳ ấn bản nào (đối với DB2 Express bạn cần sử dụng giấy phép FTL, hoặc giấy phép SERVER, hoặc bạn cần phải mua gói tính năng), đó là hệ thống tự động Tivoli cho nhiều nền tảng (Tivoli SA- MP), để tạo ra cụm khả năng sẵn sàng cao cho máy chủ DB2 của bạn (như DB2 9).  Bạn không cần phải mua giấy phép sử dụng máy chủ dự phòng lạnh (như trường hợp DB2 9.5). Thực tế, một số nhà cung cấp tuyên bố rằng họ mang lại một số lợi thế bằng cách tặng 10 ngày sử dụng chuyển đổi dự phòng cho giải pháp khả năng sẵn sàng cao, tuy nhiên, đối với DB2, điều này thực sự là không giới hạn cho loại cụm tương tự. Hơn nữa, bạn có được phần mềm phân cụm miễn phí! Trên thực tế, phần mềm phân cụm Tivoli SA-MP được tích hợp sâu vào DB2 (DB2 9.5) và bao gồm các giao diện quản lý phong phú giảm bớt tổng chi phí sở hữu của cụm khả năng sẵn sàng cao.  Bạn có thể định cấu hình hai máy chủ DB2 Express trong một cụm HADR mà không phải mua gói Tính năng sẵn sàng cao nếu bạn mua giấy phép sử dụng máy chủ DB2 Express của bạn theo giấy phép FTL hoặc giấy phép SERVER (cả hai tùy chọn giấy phép được đưa vào khi DB2 9.7 trở nên có sẵn một cách rộng rãi). Lưu ý: Trong bài viết này chúng tôi bàn về mua giấy phép sử dụng máy chủ, tuy nhiên, tất cả các phiên bản DB2 hỗ trợ giấy phép sử dụng khả năng con, tức là bạn chỉ mua giấy phép sử dụng khả năng mà máy chủ DB2 đang sử dụng. Nếu chúng ta sử dụng một câu chẳng hạn như giấy phép sử dụng cho mức PVU của máy chủ, bạn có thể hiểu là mức PVU của một phiên VMWWare hoặc LPAR, nếu bạn đang sử dụng các công nghệ ảo hóa này. Có một số điều kiện tiên quyết đối với loại giấy phép sử dụng mà bạn nên biết. Do đó hãy đảm bảo rằng bạn biết tất cả các chi tiết trước khi triển khai DB2 trong loại môi trường này. Như bạn có thể thấy, đã có rất nhiều thay đổi để giảm tổng chi phí sở hữu gắn với các cụm khả năng sẵn sàng cao của DB2 từ cả hai góc độ giấy phép sử dụng và quản trị, điều này thật phấn khởi nếu xét đến cuộc sống kinh tế của chúng ta hiện nay. Tốt nhất hãy bắt đầu cuộc tranh luận về các tác động của các cụm khả năng sẵn sàng cao với chế độ giấy phép sử dụng DB2 9.7 là với các ví dụ so sánh tương quan với cách phân loại khả năng sẵn sàng cao của DB2. Như đã đề cập ở phần trước, DB2 9.7 định nghĩa 3 loại máy chủ dự phòng, đó là: Nóng, ấm và lạnh. Về đầu trang Dự phòng nóng Cấu hình dự phòng nóng là cấu hình trong đó tất cả các máy chủ có cơ sở dữ liệu DB2 đang hoạt động phục vụ các giao dịch và truy vấn của người sử dụng. Cấu hình này được gọi là cụm nóng/nóng (hot/hot - mặc dù nó đôi khi được gọi là cấu hình tích cực/tích cực (active/active) vì tất cả các máy chủ trong cụm đang thực hiện một số công việc nghiệp vụ ở mức độ sản xuất nào đó tại mọi thời điểm). Nếu một trong các máy chủ trong cụm khả năng sẵn sàng cao bị lỗi, thì sau đó phần mềm phân cụm sẽ phân phối lại khối lượng công việc của máy chủ bị lỗi cho một hoặc nhiều máy chủ đang còn làm việc trong cụm khả năng sẵn sàng cao. Môi trường này giống như một ứng dụng đơn hoặc một ứng dụng mà mỗi máy chủ chống đỡ cho máy chủ khác, nhưng nó cũng có thỏa thuận mức dịch vụ riêng (SLA) của mình mà nó phải tuân thủ. Nếu lỗi xảy ra trong một trong các máy chủ, thì việc chuyển giao tài nguyên có thể thực sự tăng gấp đôi (tại cụm hai nút) khối lượng công việc trên máy chủ dự phòng nóng (Ví dụ: Máy chủ còn làm việc duy nhất trong cụm HADR hai nút) vì bây giờ nó phải xử lý khối lượng công việc vốn là của nó từ ban đầu cộng thêm khối lượng công việc của máy chủ bị lỗi. Đó là những gì mà bạn cần xem xét khi thiết lập bất kỳ môi trường khả năng sẵn sàng cao nào và không tận dụng các hình trạng cụm tiên tiến chẳng hạn như DB2 pureScale. Nếu bạn là quản trị viên cơ sở dữ liệu (DBA) đang sắp đặt mọi thứ để đảm bảo một thỏa thuận mức dịch vụ (SLA) chặt chẽ, bạn phải đảm bảo rằng bạn đã xem xét chặt chẽ hình trạng khả năng sẵn sàng cao (HA) của mình và lựa chọn giải pháp HA bạn đang sử dụng. Tóm lại, trong DB2 máy chủ dự phòng nóng là bất kỳ máy nào đang được sử dụng để phục vụ các giao dịch và các truy vấn của người sử dụng trong chu kỳ hoạt động bình thường, nhưng nó hành động như một máy chủ dự phòng cho một máy chủ khác cũng được sử dụng để phục vụ các giao dịch và các truy vấn của người sử dụng trong chu kỳ hoạt động bình thường. Khi lỗi của máy chủ trong cụm xảy ra, thì máy chủ dự phòng nóng tiếp nhận công việc của máy chủ bị lỗi cộng với công việc mà nó vẫn đang làm trong khi hoạt động bình thường. Vì rằng máy chủ dự phòng tích cực vẫn được sử dụng cho các giao dịch và truy vấn của người sử dụng, thì ngay cả khi không có lỗi hỏng hóc xẩy ra, nó phải được mua giấy phép đầy đủ. Ví dụ: Bạn hãy tưởng tượng là bạn có hai cơ sở dữ liệu trên hai máy chủ riêng biệt, một máy chạy ứng dụng đóng gói hoạch định nguồn lực doanh nghiệp (ERP) và máy kia chạy ứng dụng đóng gói quản lý chuỗi cung ứng (SCM). Nếu cơ sở dữ liệu SCM bị lỗi, thì máy đang chạy khối lượng công việc của ERP phải phục vụ tất cả người sử dụng SCM. Kịch bản minh họa cụm khả năng sẵn sàng cao của máy chủ dự phòng nóng hai nút được mô tả trong Hình 2. Hình 2. Máy chủ 1 là máy chủ dự phòng nóng cho máy chủ 2 và máy chủ 2 là máy chủ dự phòng nóng cho máy chủ 1. Tải công việc của máy chủ 2 chuyển sang máy chủ 1 trong trường hợp lỗi xảy ra và ngược lại. Trong ví dụ này có một cặp máy chủ mà cả hai đang được sử dụng cho tải công việc giao dịch và truy vấn trong chu kỳ hoạt động bình thường (các hình hộp tô đặc đại diện cho tải công việc của từng máy chủ trước khi có lỗi, các hình hộp có đường kẻ chéo song song là nơi công việc diễn ra trong trường hợp xẩy ra lỗi ở máy chủ tương ứng). Trong tình huống giả định này, máy 2 bị lỗi và tải công việc của nó được chuyển giao cho đối tác dự phòng của nó, là máy chủ 1. Máy chủ 1 là một máy chủ dự phòng nóng cho máy chủ 2 (và ngược lại khi bạn nhìn kỹ hình này – hãy lưu ý hình hộp có đường kẻ chéo song song cho máy chủ 1 ở máy chủ 2). Kiểu cấu hình này thường được gọi là cặp cụm khả năng sẵn sàng cao, cặp chuyển đổi sinh đôi, cặp nóng/nóng hoặc cặp tích cực/tích cực và rất phổ biến trong bối cảnh công nghệ thông tin ngày nay. Có rất nhiều cách để thực hiện cụm khả năng sẵn sàng cao nóng/nóng trong DB2 và phụ thuộc vào bạn cần gì trong giải pháp, bạn có thể sử dụng PowerHA cho AIX, HADR kết hợp với cơ sở dữ liệu trên mỗi máy chủ chuyển đổi dự phòng sang máy khác, HADR (Với khả năng Đọc trên máy chủ dự phòng (Read on Standby) được kích hoạt), Q-Replication, bằng cách sử dụng dự phòng nóng cho việc báo cáo thông qua công nghệ ảnh chụp nhanh hoặc sao ảnh đĩa, hoặc đỉnh cao của việc kết hợp khả năng mở rộng và khả năng sẵn sàng: hãy sử dụng công nghệ DB2 pureScale. Một lần nữa, cả máy chủ 1 và máy chủ 2 trong Hình 2 đã được sử dụng cùng nhau cho tải công việc sản xuất; khi máy 2 gặp lỗi, tải công việc của DB2 của nó được chuyển sang máy chủ 1 một cách dễ dàng. Cụm HADR có thể hoạt động như cụm nóng/nóng theo nhiều cách. Ví dụ: Bạn hãy xem xét môi trường trong Hình 3. Hình 3. Cụm HADR nóng/ nóng nhờ có cụm chuyển đổi dự phòng lẫn nhau HADR Trong hình trước bạn có thể thấy rằng máy chủ A chủ chứa cơ sở dữ liệu sản xuất gọi là cơ sở dữ liệu A cũng như cơ sở dữ liệu dự phòng trong cụm HADR được gọi cơ sở dữ liệu B1. Cùng lúc đó, máy chủ B chủ chứa cơ sở dữ liệu sản xuất gọi là cơ sở dữ liệu B cũng như một cơ sở dữ liệu dự phòng trong cùng cụm HADR được gọi là cơ sở dữ liệu A1. Trong trường hợp này, khi không có l