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)

Chia sẻ: Nhung Nhung | Ngày: | Loại File: PDF | Số trang:21

Thêm vào BST

Báo xấu

87
lượt xem 4
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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 đề...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: 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 Phần mềm cơ sở dữ liệu được Phần mềm cơ sở dữ liệu được DB2 được cài đặt trên máy chủ cài đặt trên máy chủ nhằm mục cài đặt trên máy chủ nhằm nhằm mục đích dự phòng đích dự phòng mục đích dự phòng Cá thể cơ sở dữ liệu được khởi Đồng thời máy chủ này duy trì chạy, và nó cũng có thể nhận kịch bản đối tác sẵn sàng cao được các thông tin cập nhật từ của của nó, nó cũng phục vụ Cá thể cơ sở dữ liệu chưa được cơ sở dữ liệu chính cho mục các ứng dụng khác như là máy khởi chạy, và sẽ được khởi chạy đích khả năng sẵn sàng cao. chủ dữ liệu chính. Có sự truy chỉ khi chuyển đổi dự phòng xảy Không có sự truy cập của cập của người dùng cuối cùng ra. người sử dụng cuối cùng nào vào cơ sở dữ liệu dự phòng vào cơ sở dữ liệu dự phòng này ngay cả khi không có lỗi này. 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 Thường sử dụng trong HADR sau thảm họa với khả năng sẵn Thường sử dụng trong HADR chuyển đổi dự phòng kép (sẽ sàng cao (HADR) hoặc việc dịch “vanilla” (không đọc ở chế độ nói thêm sau), trong HADR có chuyển bản ghi nhật ký không chờ), trong Q-Replication, đọc ở chế độ chờ, trong DB2 được triển khai và trình quản lý cơ hoặc trong kịch bản dịch pureScale, và trong các kịch sở dữ liệu không được chạy, chuyển bản ghi nhật ký. bản tạo bản đúp chẳng hạn như cho PowerHA cho cụm AIX (trước đây là HACMP). 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ỗi, cả hai máy chủ A và B đều bận phục vụ công việc sản xuất trên cơ sở dữ liệu A và B tương ứng, và do đó nó được xem là cấu hình nóng/nóng và cả hai máy chủ phải được mua giấy phép đầy đủ. Hình 4 là ví dụ về môi trường HADR đang sử dụng khả năng Đọc trong chế độ dự phòng, là một phần của gói vá lỗi 1 của DB2 phiên bản 9.7 và các phiên bản sau này. Hình 4. Cụm HADR nóng/nóng nhờ có Đọc trong chế độ dự phòng Trên hình 4 bạn có thể thấy rằng các trình khách có thể đọc và ghi vào máy chủ chính (làm cho nó thành nóng); nhưng, vì chúng đang đọc trên máy chủ thứ cấp, máy chủ này cũng là nóng và do đó cả hai máy chủ phải được mua giấy phép đầy đủ. Khá đơn giản, nếu bạn đọc dữ liệu từ một máy chủ cho mục đích kinh doanh, đó là một máy nóng. Cuối cùng, Hình 5 cho thấy một cụm 3 thành viên pureScale DB2 khả năng sẵn sàng cao và co giãn.
Hình 5. Một cụm DB2 pureScale Trong hình 5, bạn chỉ mua giấy phép cho DB2 và gói tính năng DB2 pureScale trên các máy chủ thành viên (các máy chủ xử lý giao dịch). Các máy chủ phương tiện nhớ sẵn (CF- Cluster Caching Facility) của cụm (mà như bạn có thể thấy thường là hoàn toàn song công) không yêu cầu bất kỳ giấy phép nào. Trong ví dụ này, vì các giao dịch đang được liên tục cân bằng tải trên tất cả các máy chủ thành viên, nên tất cả các máy chủ là nóng và do đó tất cả chúng đều phải được mua giấy phép đầy đủ. Các xem xét khi mua giấy phép cho một máy chủ dự phòng nóng Như một quy tắc ngón tay cái chung, cấu hình nóng/nóng cần được mua giấy phép giống như cách mà bạn mua giấy phép cho từng máy chủ, khi chúng hoàn toàn không được phân cụm để có tính sẵn sàng cao. Từ DB2 phiên bản 9.7 trở đi, có năm phương thức mua giấy phép khác nhau (một số chỉ có sẵn với các phiên bản DB2 cụ thể): đó là SERVER, Giấy phép ấn định thời hạn (FTL), SOCKET, Người dùng có thẩm quyền (AU), và Giá trị đơn vị bộ xử lý (PVU). Phần sau sẽ chi tiết các cân nhắc về mua giấy phép khả năng sẵn sàng cao mà bạn cần phải nhận thức được cho mỗi giấy phép tương ứng trong cụm khả năng sẵn sàng cao nóng/nóng. Giấy phép SERVER Giấy phép SERVER là mới đối với DB2 9.7 và chỉ có sẵn cho các máy chủ DB2 Express. Khi mua giấy phép SERVER cho máy chủ DB2 Express, đơn giản là bạn mua mua giấy phép cho mỗi máy chủ trong cụm bất kể loại máy chủ dự phòng là gì (nóng, ấm hoặc lạnh). Rất đơn giản, không cần phải xác định mức độ tích cực của máy chủ DB2 Express được mua giấy phép SERVER khi liên quan đến giấy phép cho khả năng sẵn sàng cao. Không có số lượng người sử dụng tối thiểu, và bạn không phải tính toán mức PVU của máy chủ ở phía dưới hoặc bất cứ điều gì khác: Quá đơn giản! Mặc dù trong một cấu hình nóng/nóng thì quy tắc này không có ảnh hưởng gì tới việc mua giấy phép (vì cả hai máy chủ đều là nóng), bạn sẽ thấy trong cấu hình dự phòng ấm, các yêu cầu mua giấy phép SERVER là khác đi so với các giấy phép DB2 khác.
Ngoài ra, nếu bạn muốn tạo ra một cụm HADR bằng cách sử dụng máy chủ DB2 Express trong DB2 9.5, bạn phải mua Gói tính năng khả năng sẵn sàng cao của DB2 để có được các tính năng này cùng với các tính năng khác liên quan đến khả năng sẵn sàng cao. Trong DB2 9.7, giấy phép SERVER của DB2 Express thực sự có kèm tất cả các tính năng trong gói tính năng sẵn sàng cao (bao gồm cả HADR) miễn phí, tuy nhiên bạn cần phải mua gói tính năng này nếu bạn muốn có HADR (hoặc các tính năng khác) cho một máy chủ DB2 Express với giấy phép có được thông qua hoặc giấy phép PVU hoặc giấy phép AU. Vì lý do này, và nhiều lý do khác, chúng tôi khuyên bạn nên mua giấy phép này (hoặc FTL) cho bất kỳ máy chủ DB2 Express nào. Giấy phép ấn định thời hạn (FTL) Mặc dù giấy phép ấn định thời hạn (FTL) là mới đối với DB2 Express phiên bản 9.7, nó có cùng phương thức định giá như giấy phép FTL cho DB2 Express-C phiên bản 9.5 cũ (không còn nữa). Giấy phép này sẽ cho phép bạn truy cập vào tất cả các tính năng trong DB2 Express (không giống như phiên bản trước của nó). Một giấy phép FTL của DB2 Express cho phép bạn truy cập vào phần mềm DB2 Express trong thời hạn là một năm - đó là giấy phép thời hạn, đối lập với giấy phép vĩnh viễn như được cung cấp với các phiên bản DB2 khác. Khi mua giấy phép FTL cho máy chủ DB2 Express, đơn giản là bạn mua giấy phép FTL cho mỗi máy chủ trong cụm – cũng giống như giấy phép SERVER cho máy chủ DB2 Express – bất kể loại máy chủ dự phòng là gì (nóng, ấm hoặc lạnh). Khá đơn giản, không cần phải xác định mức độ tích cực của máy chủ DB2 Express được mua giấy phép nếu sử dụng giấy phép FTL khi liên quan đến mua giấy phép cho khả năng sẵn sàng cao. Không có số người sử dụng tối thiểu, và bạn không phải tính toán mức PVU của máy chủ ở bên dưới hoặc bất cứ điều gì khác: Quá đơn giản! Mặc dù trong một cấu hình nóng/nóng thì quy tắc này không có ảnh hưởng gì tới việc mua giấy phép (vì cả hai máy chủ đều là nóng), bạn sẽ thấy trong cấu hình dự phòng ấm, các yêu cầu mua giấy phép là khác đi so với các giấy phép DB2 khác. Một máy chủ DB2 Express được mua giấy phép FTL cung cấp cho bạn khả năng truy cập vào tất cả các tính năng trong gói tính năng sẵn sàng cao của DB2, bao gồm cả HADR. (Tuy nhiên, hãy lưu ý rằng bạn phải mua gói này tính năng để kích hoạt HADR, trong số các tính năng sẵn sàng cao khác, nếu bạn đang sử dụng giấy phép PVU hoặc AU của DB2 Express). Vì lý do này, và nhiều lý do khác, chúng tôi khuyên bạn nên mua giấy phép này (hoặc giấy phép SERVER) cho bất kỳ máy chủ DB2 Express nào. Giấy phép SOCKET (Ổ cắm) Giấy phép SOCKET là mới đối với DB2 9.7 và chỉ có sẵn cho các máy chủ DB2Workgroup. Khi mua giấy phép SOCKET cho máy chủ DB2Workgroup, đơn giản là bạn mua giấy phép cho cùng số lượng ổ cắm như trên các máy chủ chính cho từng máy chủ vì đây là cấu hình nóng/nóng và tất cả các máy chủ được sử dụng đầy đủ cho các hoạt động thường xuyên. Ví dụ: Nếu bạn có máy chủ lõi kép 4 đường Power7 của IBM, bạn sẽ cần mua giấy phép cho 4 SOCKET DB2Workgroup. Thật ngẫu nhiên, máy chủ này sẽ được tính ở mức 960 PVU và bạn cũng sẽ vẫn cần mua giấy phép cho 4 SOCKET DB2Workgroup. Đối với cấu hình nóng/nóng, bạn sẽ cần giấy phép cho 8 SOCKET cho DB2Workgroup: 4 ổ cắm
cho máy chủ chính nóng và 4 ổ cắm cho máy chủ dự phòng nóng. Bất cứ khi nào mua giấy phép cho máy chủ DB2Workgroup, chúng tôi khuyên bạn nên sử dụng giấy phép này vì các khả năng bộ xử lý trung tâm được bổ sung thêm mà nó cung cấp cho môi trường của bạn. Giấy phép đơn vị giá trị bộ xử lý (PVU - Processor Value Unit) Bất kỳ máy chủ DB2 nào đều có thể mua giấy phép bằng cách sử dụng mô hình PVU. Trong cấu hình tích cực/tích cực, toàn bộ mức PVU của máy chủ dự phòng nóng (máy chủ 1 trong ví dụ của chúng ta) phải được mua giấy phép bổ sung. Tất nhiên, bạn sẽ sử dụng cùng cách tiếp cận này để mua giấy phép cho máy chủ DB2 của bạn ngay cả khi nó không phải là một phần của cụm khả năng sẵn sàng cao vì dẫu sao, nó vẫn đang phục vụ công việc sản xuất, do đó không có bất kỳ điều gì ngạc nhiên ở đây. Nếu các máy chủ trong Hình 3 sử dụng bốn lõi của máy chủ Power7, và giả sử rằng mỗi máy chủ chạy DB2Workgroup (bị giới hạn với giấy phép này cho các máy chủ với mức tối đa là 480 PVU như vào quý 2 năm 2008 (2Q08)), bạn sẽ phải mua tổng cộng 960 PVU cho giải pháp này: 480 PVU cho máy chủ 1 và 480 PVU cho máy chủ 2. Giấy phép người dùng được ủy quyền (AU) Đối với bất kỳ sản phẩm máy chủ DB2 nào đã mua giấy phép theo mô hình AU, bạn phải mua giấy phép cho môi trường như vậy bằng cách mua tổng số AU sẽ truy cập vào môi trường đó trên máy chủ chính nóng, cộng thêm số lượng tương ứng của người dùng sẽ truy cập vào máy chủ dự phòng nóng nữa (vì chúng cả hai thực sự đều là máy chủ nóng cho các ứng dụng của riêng mình và các máy chủ dự phòng cho máy chủ kia). Một AU là một cá thể riêng lẻ (trong một số trường hợp, nó có thể là một ứng dụng hoặc một thiết bị chừng nào nó không hành động thay mặt cho những người dùng khác) với một danh tính cụ thể nằm bên trong hoặc bên ngoài công ty của bạn. Những giấy phép này cũng có thể được sử dụng trên Internet (giống như ứng dụng mua bán trực tuyến) người sử dụng cuối cùng được biết rõ vì họ phải được xác định danh tính một cách cụ thể cho giấy phép này. Các giấy phép AU là giấy phép đầy đủ, không cần có giấy phép tách riêng cho máy chủ như đã từng xảy ra trước đây với DB2 8, lúc đó bạn cần phải mua giấy phép người sử dụng cùng với giấy phép máy chủ cơ sở. Nếu bạn đang sử dụng ghép kênh hoặc phần mềm kết nối tập trung, thì những người dùng cần phải được xác định danh tính và liệt kê trước khi các công nghệ như vậy được áp dụng cho các kết nối được đếm. Bạn cần một giấy phép AU cho bất cứ ai truy cập vào máy chủ. Tuy nhiên, bất kể số lượng người dùng truy cập vào máy chủ của bạn là bao nhiêu, có một số tối thiểu người dùng tùy theo từng ấn bản mà bạn cần phải tính đến. Các ấn bản của DB2Express hoặc DB2 Workgroup yêu cầu tối thiểu năm giấy phép AU. DB2 Enterprise đòi hỏi tối thiểu là 25 AU cho 100 PVU cho máy chủ bên dưới. Nói một cách khác, cứ mỗi 100 PVU trên máy chủ, bạn cần một gói 25-AU. Ví dụ: Một máy chủ với 480 PVU sẽ yêu cầu mức tối thiểu là giấy phép 125 AU vì bạn làm tròn số PVU để xác định số lượng tối thiểu người dùng. Tất nhiên, nếu bạn đã có 150 người dùng, thì bạn sẽ cần phải mua giấy phép máy chủ nhiều hơn số lượng tối thiểu để bằng với số lượng thực tế sử dụng, trong trường hợp này là 150 AU. Giấy phép AU không được chuyển nhượng qua các ca làm việc (mặc dù
chúng có thể được chuyển giao khi thay đổi nhân viên), và chúng chỉ có giá trị cho một máy chủ cụ thể. Tất nhiên vì hình 3 là một ví dụ về cấu hình nóng/nóng, các quy tắc này là chưa rõ ràng bởi vì, dù sao đi nữa chúng phải được mua giấy phép như các máy chủ độc lập. Trong ví dụ trong hình 3, nếu bạn có 100 người sử dụng cần phải truy cập vào cả hai máy chủ nóng DB2 Workgroup, bạn sẽ cần phải mua tổng cộng là 200 giấy phép AU của DB2 Workgroup cho 100 người dùng này: 2 máy chủ x 100 AU mỗi máy chủ. Ngay cả khi chỉ có 12 trong số những người sử dụng này kết nối với một trong hai máy chủ tại bất cứ thời điểm nào, tất cả 100 người dùng vẫn sẽ phải được mua giấy phép cho mỗi máy chủ (vì vậy bạn vẫn cần 200 giấy phép AU cho ví dụ này). Nếu bạn đang sử dụng DB2 Express hoặc DB2Workgroup trong hình 3, và bạn chỉ có 3 người sử dụng trong công ty của bạn, bạn sẽ cần tổng cộng 10 giấy phép AU cho DB2 Express hoặc DB2 Workgroup (2 máy chủ x 5 AU tối thiểu) để đáp ứng yêu cầu tối thiểu về AU gắn với các phiên bản này của DB2. Nếu các máy chủ được sử dụng trong hình 3 là DB2 Enterprise, như đã đề cập ở phần trước, mọi thứ khác đi một chút: chúng ta hãy tiếp tục với ví dụ mà chúng ta giả định rằng mỗi máy chủ là máy chủ dựa trên Power7 4 lõi ở mức 480 PVU. Nếu bạn có 100 người sử dụng tất cả đều cần truy cập vào máy chủ DB2 Enterprise nóng, bạn sẽ cần phải mua tổng cộng 250 giấy phép AU DB2 Enterprise cho 100 người dùng: 2 máy chủ x 125 AU mỗi máy chủ vì tối thiểu là 25 người sử dụng cho mỗi 100 PVU cho từng máy chủ DB2 Enterprise. Một lần nữa, ngay cả khi chỉ có 12 trong số những người dùng kết nối với một trong hai máy chủ DB2 cùng một lúc, tất cả 125 người vẫn phải được mua giấy phép cho mỗi máy chủ. Về đầu trang Dự phòng ấm Cấu hình dự phòng ấm là một cấu hình trong trong đó có ít nhất một máy chủ trong cụm khả năng sẵn sàng cao không có một cơ sở dữ liệu DB2 đang phục vụ tải công việc giao dịch hoặc truy vấn của người sử dụng trong thời gian hoạt động bình thường. Máy chủ này là ấm theo nghĩa rằng máy chủ không thực hiện các công việc "hữu ích". Công việc được phân loại là "không hữu ích" (mặc dù trớ trêu thay nó có thể là công việc hữu ích nhất mà máy chủ dự phòng của bạn thực hiện) bao gồm các hoạt động quản trị hỗ trợ trong kịch bản chuyển đổi dự phòng chẳng hạn như có một cơ sở dữ liệu ở trạng thái treo chờ cuộn tiến (rollforward) để hỗ trợ dịch chuyển ghi nhật ký, hỗ trợ dịch chuyển ghi nhật ký mức giao dịch cho môi trường HADR, và v.v.. Nếu một trong các máy chủ trong cụm khả năng sẵn sàng cao gặp sự cố, thì sau đó tải công việc được phân phối lại cho máy chủ dự phòng ấm. Một quan niệm sai lầm phổ biến mà nhiều người mắc phải về cấu hình chế độ chờ ấm là máy chủ dự phòng ấm là một sự lãng phí về tài nguyên khi nó chỉ được dành riêng cho hoạt động phục hồi. Đây là một sự hiểu biết không chính xác về loại cấu hình này. Sự thật là bạn có thể sử dụng máy chủ dự phòng ấm cho nhiều công việc (công việc liên quan đến DB2 và cả không liên quan đến DB2) vượt ra ngoài vai trò là máy chủ dự phòng. Ví dụ: Bạn có thể tạo ra một cá thể DB2
riêng biệt trên máy chủ dự phòng ấm (tùy thuộc vào công việc liên quan đến DB2 mà bạn chọn để thực hiện ở đây, nó có thể kéo theo phải mua giấy phép) và sử dụng nó như một máy chủ thử nghiệm, hoặc có thể chuyển bớt tải công việc và chức năng khác sang cho nó. Trong trường hợp sự cố, bạn có thể co bớt lại các khối lượng công việc này (hoặc các nguồn tài nguyên đã phân bổ cho phân vùng ảo hóa mà máy chủ chạy) và cho phép máy chủ dự phòng ấm sử dụng tất cả tài nguyên của máy chủ để xử lý tải của máy chủ gặp lỗi và như vậy né tránh được những tính toán về tải công việc được nêu trong phần thảo luận về dự phòng nóng/nóng trong phần cuối của bài viết. Kịch bản dự phòng ấm được thể hiện trong hình 6. Trong hình này, cấu hình HADR “vanilla” (khả năng Đọc trong dự phòng không được sử dụng) đã được tạo ra cho môi trường OLTP sản xuất. Trong ví dụ này, trong suốt thời gian hoạt động bình thường, máy chủ 2 đang được sử dụng cho tải công việc giao dịch và truy vấn (được ghi chú là công việc tích cực - ActiveWork trong hình), trong khi máy chủ 1 đang chờ như là máy chủ dự phòng ấm cho tải công việc của máy chủ 2. Máy chủ 2 bị lỗi và tải công việc DB2 của nó được chuyển sang máy chủ 1 là đối tác ấm của nó. Trong kịch bản này, rất có thể xảy ra trường hợp là nếu bất kỳ công việc nào (bất kỳ loại nào) được thực hiện trên máy chủ 1 trước khi có lỗi, nó sẽ được thu nhỏ lại để xử lý tải công việc mới sau khi xảy ra lỗi ở máy chủ 2 (hoặc máy chủ 1 ban đầu được định cỡ để hỗ trợ tải công việc của nó và tải công việc của máy chủ 2 cùng một lúc, nếu không bạn sẽ gặp vấn đề về hiệu năng). Hình 6. Khối lượng công việc của máy chủ 2 được chuyển giao cho máy chủ dự phòng ấm, là máy chủ 1 trong cụm HADR điển hình
Bởi vì trong suốt thời gian hoạt động bình thường chỉ có một máy chủ là nóng từ góc nhìn của DB2 trong hình 6 trong khi máy chủ khác đang làm một số hoạt động ấm như chuẩn bị sẵn sang làm một đối tác chuyển đổi dự phòng HADR, cấu hình này thường được gọi là nóng/ấm (hoặc tích cực/nhàn rỗi, trong một số giới chuyên môn). Khái niệm quan trọng cần được lưu ý ở đây là máy chủ 1 không làm bất kỳ công việc DB2 "có ý nghĩa" nào trước khi sự cố ngừng chạy xảy ra. Tất nhiên trong kịch bản HADR Đọc trong dự phòng hoặc DB2pureScale, 'máy chủ dự phòng' (không thực sự là đứng chờ dự phòng nữa vì nó là nóng) đang làm công việc có ý nghĩa và do đó không công nghệ nào trong các công nghệ này được kết hợp với mức dự phòng ấm hoặc lạnh. Khách hàng có tất cả mọi loại tiếp cận khác nhau tới máy chủ dự phòng. Chúng tôi khuyên bạn nên ưu tiên mục tiêu của bạn và các yêu cầu nghiệp vụ liên quan đến máy chủ dự phòng. Ví dụ, một số khách hàng có thể chọn thiết lập một môi trường khả năng sẵn sàng cao trên một máy chủ dự phòng và đồng thời sử dụng cơ sở dữ liệu dự phòng cho một dạng phiên bản chỉ đọc hiện trạng của máy chủ sản xuất - do đó làm lan rộng phân bổ chi phí trên ngày càng nhiều tài nguyên; bạn có thể làm điều này với HADR kể từ gói vá lỗi 1 của DB2 9.7 hoặc các gói vá lỗi sau đó. Bạn nên lưu ý rằng nhiều nhà cung cấp giới hạn mô hình này là một trong hai việc trên, có nghĩa rằng trong khi bạn đang đọc cơ sở dữ liệu, bạn không có thể cuộn tiến về phía trước thông qua bản ghi nhật ký để giữ cho nó như hiện trạng (nếu không phải là trường hợp chọn một trong hai, thì sẽ có sự thỏa hiệp về quá trình xử lý làm lại (redo) có thể chạy nhanh đến đâu, chưa kể những cân nhắc khác). Tiếp theo nữa, việc để cơ sở dữ liệu mở trong thời gian dài hoạt động chỉ đọc trong môi trường như vậy làm tăng thời gian trung bình để sửa chữa (MTTR - mean time to repair) trong trường hợp có lỗi: đó chính là vấn đề mà cấu hình này được thiết kế để tránh xảy ra. Một ví dụ khác là với việc đọc các cơ sở dữ liệu OLTP dự phòng. Nếu bạn nghĩ về nó, thì cơ sở dữ liệu OLTP được thiết kế để có các chỉ số tối thiểu. Nếu bạn bắt đầu chạy một tải công việc giống với tạo báo cáo trên máy chủ dự phòng của nó, thì cơ sở dữ liệu dự phòng nhiều khả năng sẽ trải nghiệm một số lần quét toàn bảng vì không có chỉ số để hỗ trợ nó tra cứu nhanh chóng. Việc chạy quét toàn bộ bảng trên một máy chủ dự phòng có thể tiêu thụ rất nhiều tài nguyên đến mức có thể gặp rắc rối khi giữ các cơ sở dữ liệu được đồng bộ. Tùy thuộc vào yêu cầu về khả năng sẵn sàng, khối lượng công việc của bạn, vân vân, máy chủ dự phòng ấm có thể hoặc không phải là sự lựa chọn đúng cho môi trường của bạn; tuy nhiên, khi lập kế hoạch cho các loại dự phòng mà bạn muốn hỗ trợ, đừng bao giờ quên lý do ở vị trí đầu tiên tại sao bạn lại cần có một môi trường khả năng sẵn sàng cao: đó là để giảm thiểu MTTR khi có sự cố ngừng chạy. Điểm quan trọng là DB2 cũng có các tùy chọn cho cấu hình nóng/nóng (bao gồm cả một số công nghệ đọc trong chế độ dự phòng HADR, công nghệ này không phải là một phần của DB2 9.7, khi nó lần đầu tiên trở nên có sẵn nhưng đã được đưa vào gói vá lỗi 1 của DB2 9.7) và tất cả các phiên bản DB2 pureScale mới. Ví dụ, nếu bạn đọc từ một máy chủ dự phòng, trong cấu hình HADR, máy chủ ngay lập tức được coi là nóng. Tóm lại, quan điểm cho rằng một máy chủ dự phòng ấm (từ quan điểm DB2) chỉ là ngồi chơi và lãng phí nguồn tài nguyên là một khái niệm thường rất hay bị hiểu lầm khi bạn thực sự nhìn vào nó - nhưng với DB2, sự lựa chọn tùy thuộc vào bạn, hãy nhớ rằng DB2 có thể cung cấp bất kỳ cấu hình nào bạn muốn. Các xem xét khi mua giấy phép cho một máy chủ dự phòng ấm
Từ DB2 phiên bản 9.7 trở đi, có năm phương thức mua giấy phép khác nhau (một số chỉ có sẵn với các phiên bản DB2 cụ thể): đó là SERVER, Giấy phép ấn định thời hạn (FTL), SOCKET, Người dùng có thẩm quyền (AU), và Giá trị đơn vị bộ xử lý (PVU). Phần sau sẽ chi tiết các cân nhắc về mua giấy phép khả năng sẵn sàng cao mà bạn cần phải nhận thức được cho mỗi giấy phép tương ứng. Giấy phép SERVER Giấy phép SERVER là mới đối với DB2 9.7 và chỉ có sẵn cho các máy chủ DB2 Express. Khi mua giấy phép SERVER cho một máy chủ DB2 Express, đơn giản là bạn mua giấy phép cho mỗi máy chủ trong cụm bất kể loại dự phòng gì (nóng, ấm, hoặc lạnh). Rất đơn giản, không cần phải xác định mức độ tích cực của máy chủ DB2 Express với giấy phép SERVER khi liên quan đến mua giấy phép cho khả năng sẵn sàng cao. Không có số lượng người sử dụng tối thiểu, và bạn cũng không phải tính toán mức PVU của máy chủ bên dưới hoặc bất cứ điều gì khác: Quá đơn giản! Ngoài ra, nếu bạn muốn tạo ra một cụm HADR bằng cách sử dụng máy chủ DB2 Express trong DB2 9.5, bạn phải mua gói tính năng khả năng sẵn sàng cao của DB2 để có tính năng này cùng với các tính năng khác liên quan đến khả năng sẵn sàng cao. Trong DB2 9.7, giấy phép SERVER DB2 Express thực sự đi kèm với tất cả các tính năng trong gói tính năng khả năng sẵn sàng cao (bao gồm cả HADR) miễn phí, tuy nhiên bạn phải mua gói tính năng này nếu bạn muốn HADR (hoặc các tính năng khác) với một máy chủ DB2 Express có giấy phép nhờ thông qua giấy phép PVU hoặc AU khác. Vì lý do này, và nhiều lý do khác, chúng tôi khuyên bạn nên sử dụng giấy phép SERVER này (hoặc giấy phép FTL) cho bất kỳ máy chủ DB2 Express nào. Trong cụm khả năng sẵn sàng cao nóng/ấm, bạn thực sự phải mua giấy phép SERVER cho mỗi máy chủ DB2 Express. Nếu bạn muốn tạo cụm HADR bằng cách sử dụng máy chủ DB2 Express trong DB2 9.5, bạn phải mua gói tính năng khả năng sẵn sàng cao của DB2 để có tính năng này cùng với các tính năng khác liên quan đến khả năng sẵn sàng cao. Trong DB2 9.7, giấy phép SERVER của DB2 Express thực sự đi kèm với tất cả các tính năng trong gói tính năng khả năng sẵn sàng cao (HADR) miễn phí. Bạn phải mua gói tính năng này nếu bạn muốn sử dụng HADR (hoặc một số công nghệ DB2 tiên tiến khác liên quan đến khả năng sẵn sàng cao) với một máy chủ DB2 Express có giấy phép nhờ thông qua giấy phép PVU hoặc AU Giấy phép ấn định thời hạn (FTL) Mặc dù giấy phép FTL là mới đối với DB2 Express phiên bản 9.7, nó có cùng phương pháp định giá như giấy phép FTL cho DB2 Express-C phiên bản 9.5 cũ (không còn nữa). Giấy phép này sẽ cho phép bạn truy cập vào tất cả các tính năng trong DB2 Express (không giống như phiên bản trước của nó). Giấy phép FTL DB2 Express cho phép bạn truy cập vào phần mềm DB2 Express trong thời hạn là một năm - đó là giấy phép ấn định thời hạn, đối lập với giấy phép vĩnh viễn như được cung cấp với các giấy phép của các phiên bản DB2 khác. Khi mua giấy phép FTL cho máy chủ DB2 Express, đơn giản là bạn mua giấy phép FTL cho mỗi máy chủ trong cụm - giống như giấy phép SERVER của DB2 Express – bất kể máy chủ dự phòng là kiểu gì (nóng, ấm hoặc lạnh). Khá đơn giản, không cần phải xác định mức độ tích cực của máy chủ DB2 Express với giấy phép FTL
khi liên quan đến mua giấy phép cho khả năng sẵn sàng cao. Không có số người sử dụng tối thiểu, và bạn không phải tính toán mức PVU của máy chủ ở bên dưới hoặc bất cứ điều gì khác: Quá đơn giản! Trong cụm khả năng sẵn sàng cao nóng/ấm, bạn thực sự phải mua giấy phép FTL cho mỗi máy chủ DB2 Express. Nếu bạn muốn tạo ra một cụm HADR bằng cách sử dụng máy chủ DB2 Express trong DB2 9.5, bạn phải mua gói tính năng khả năng sẵn sàng cao của DB2 để có tính năng này cùng với các tính năng khác liên quan đến khả năng sẵn sàng cao. Trong DB2 9.7, giấy phép FTL của DB2 Express thực đi cùng với tất cả các thành phần của gói tính năng sẵn sàng cao (bao gồm cả HADR) miễn phí; Thực vậy, giấy phép FTL của DB2 Express cho phép bạn có tất cả các tính năng có sẵn trong gói tính năng khả năng sẵn sàng cao của DB2! Bạn phải mua gói tính năng này nếu bạn muốn HADR (hoặc một số công nghệ DB2 tiên tiến khác liên quan đến khả năng sẵn sàng cao) với một máy chủ DB2 Express có giấy phép nhờ thông qua giấy phép PVU hoặc AU. Vì lý do này, và nhiều lý do khác, chúng tôi đặc biệt khuyên bạn nên sử dụng giấy phép này (hoặc giấy phép SERVER) cho bất kỳ máy chủ DB2 Express nào. Giấy phép SOCKET Giấy phép SOCKET cũng là mới đối với DB2 9.7 và chỉ có sẵn cho các máy chủ của DB2 Workgroup. Khi mua giấy phép SOCKET cho máy chủ DB2Workgroup, đơn giản là bạn mua giấy phép cho số lượng ổ cắm (sockets) mà DB2 sẽ sử dụng trên các máy chủ chính. Nếu bạn có máy chủ Power7 lõi kép 4 đường của IBM, bạn cần mua 4 giấy phép SOCKET cho DB2Workgroup. Đối với các máy chủ dự phòng ấm, bạn chỉ cần mua bổ sung một giấy phép SOCKET bất kể là ổ nào. Trong ví dụ hình 6, bạn sẽ cần 4 ổ cắm (cho máy chủ nóng) + 1ổ căm (cho máy chủ dự phòng ấm) = 5 ổ cắm. Một cách ngẫu nhiên, máy chủ chính sẽ được tính ở mức 960 PVU và bạn vẫn sẽ cần mua 4 giấy phép SOCKET cho DB2 Workgroup. Bất cứ khi nào bạn mua giấy phép cho máy chủ DB2 Workgroup, chúng tôi khuyên bạn nên sử dụng giấy phép này vì năng lực bộ xử lý trung tâm bổ sung mà nó cung cấp cho môi trường của bạn. Giấy phép đơn vị giá trị bộ xử lý (PVU - Processor Value Unit) Đối với bất kỳ máy chủ DB2 nào được mua giấy phép bằng cách sử dụng mô hình PVU, bạn cần mua giấy phép một máy chủ dự phòng ấm cho 100 PVU bất kể kiến trúc lõi xử lý mà máy chủ dựa trên nó là gì. Nói cách khác, nếu một máy chủ có bốn bộ xử lý AMD lõi tứ, tương đương với 800 PVU và một máy chủ Power7 với hai bộ xử lý lõi tứ, tương đương với 960 PVU, với một máy chủ dự phòng ấm, bạn chỉ cần mua giấy phép cho máy chủ đó với 100 PVU của các phiên bản DB2 tương ứng. Ví dụ: Nếu máy chủ trong hình 6 chỉ sử dụng bốn lõi của máy chủ Power7, và giả sử mỗi máy chủ chạy DB2 Workgroup (không còn giới hạn chỉ cho các máy chủ với mức tối đa là 480-PVU kể từ tháng 6 năm 2011), bạn sẽ phải mua tổng cộng là 580 PVU cho giải pháp này: (480 PVU cho máy chủ 2 + 100 PVU cho máy chủ dự phòng ấm 1). Ghi chú: Kể từ tháng 6 năm 2011, mức hạn chế 480 PVU đã được gỡ bỏ. Điều này có nghĩa là bây giờ bạn có thể cài đặt và sử dụng DB2 Workgroup trên máy chủ vật lý hay ảo với hơn 480 PVU, với điều kiện là bạn đã mua giấy phép một cách thích hợp cho tất
cả các PVU mà DB2 Workgroup có quyền truy cập, lên đến 16 lõi. Nếu các máy chủ vật lý hay ảo có hơn 16 lõi, bạn vẫn chỉ trả tiền cho 16 lõi thôi bởi vì đó là tất cả các lõi mà DB2 sẽ sử dụng. Điều này áp dụng cho phiên bản 9.5 và 9.7. Giấy phép người dùng được ủy quyền (AU) Đối với bất kỳ máy chủ DB2 nào đã mua giấy phép theo mô hình AU, bạn phải mua giấy phép cho máy chủ dự phòng ấm bằng cách mua số lượng AU tối thiểu cho phiên bản đó để máy chủ đó trở thành một máy chủ dự phòng ấm. Đối với DB2 Express và DB2 Workgroup, bởi vì số lượng tối thiểu AU bạn phải mua giấy phép là 5 cho bất kỳ cài đặt nào, một máy chủ dự phòng ấm yêu cầu 5 giấy phép AU. Trong hình 6, nếu một máy chủ của DB2 Workgroup là nóng và đã được định cấu hình để tham gia vào cụm HADR nóng/ấm, và bạn có 100 người sử dụng, bạn sẽ cần phải mua tổng cộng 105 giấy phép AU cho DB2 Workgroup cho 100 người sử dụng: 100 AU + 5 AU cho máy chủ dự phòng ấm. (Tất nhiên, số lượng tối thiểu của giấy phép AU cho máy chủ nóng cần phải được đáp ứng nếu số lượng người dùng ít hơn số lượng yêu cầu tối thiểu.) Nếu hình 6 sử dụng DB2 Enterprise, mọi thứ có khác một chút và thừa nhận rằng có một chút khó hiểu hơn. Trong DB2 Enterprise, số lượng tối thiểu là 25AU cho mỗi 100 PVU (đã được trình bày chi tiết ở phần trước của bài viết này). Vì bạn phải mua giấy phép tối thiểu 100 PVU cho máy chủ dự phòng ấm trong mô hình PVU với máy chủ DB2 Enterprise, bạn chuyển đổi 100 PVU tối thiểu thành 25 AU và nó trở thành số lượng AU tối thiểu cần thiết cho một máy chủ dự phòng ấm của DB2 Enterprise được mua giấy phép bằng cách sử dụng mô hình AU. Chúng ta hãy làm rõ bằng việc sử dụng ví dụ trong hình 6. Nếu các máy chủ trong hình 6 là các máy chủ hai ổ cắm lõi kép dựa trên Intel x86, thì tổng mức PVU cho máy chủ nóng sẽ là 200 PVU. Nếu bạn chỉ có ba người dùng truy cập vào máy chủ nóng DB2 Enterprise, bạn vẫn sẽ cần tổng cộng 75 AU cho cấu hình này: (200/100 = 2 x 25 AU) cho máy chủ nóng cộng với 25 AU cho máy chủ dự phòng ấm của DB2 Enterprise. Tuy nhiên, nếu các máy chủ trong hình 6 là các máy chủ hai ổ cắm lõi kép Power7 (do đó, có tổng cộng 4 lõi trên máy chủ này), mức PVU tổng cộng cho máy chủ nóng sẽ là 480 PVU. Nếu bạn chỉ có ba người dùng truy cập vào máy chủ nóng của DB2 Enterprise, bạn sẽ cần tổng cộng là 150 AU cho cấu hình này: (480/100 = 4.8 làm tròn lên là 5 x 25 AU cho máy chủ nóng = 125 AU) + 25 AU tối thiểu cho máy chủ dự phòng ấm của DB2 Enterprise. Về đầu trang Dự phòng lạnh Cấu hình dự phòng lạnh là cấu hình trong đó ít nhất một máy chủ trong cụm không có cơ sở dữ liệu DB2 đang phục vụ các tải công việc giao dịch hoặc truy vấn của người sử dụng trong thời gian hoạt động bình thường và nó không thực hiện bất cứ hành động quản trị nào để hỗ trợ kịch bản chuyển đổi dự phòng chẳng hạn như có cơ sở dữ liệu ở trạng thái treo chờ cuộn tiến (rollforward) để hỗ trợ HADR, trên thực tế, máy chủ lạnh có thể thậm chí không được cắm nguồn điện. Kịch bản dự phòng lạnh được thể hiện trong Hình 7.
Hình 7. Máy chủ 1 là máy chủ dự phòng lạnh cho máy chủ 2 Trong ví dụ này, trong thời gian hoạt động bình thường, máy chủ 2 đang sử dụng cho tải công việc truy vấn và giao dịch (được ghi chú là Active Work – Làm việc chủ động - trong hình), trong khi máy chủ 1 không có cá thể DB2 đã chạy. Có thể thậm chí là DB2 được cài đặt trên máy chủ và máy chủ đó bị ngắt điện, trong trường hợp có lỗi, máy chủ 1 được khởi động, được hồi lại đến một thời điểm nào đó từ ảnh sao lưu, và mở lên cho các giao dịch của người dùng. Cũng có thể là trường hợp máy chủ 1 được cấu hình để là một phần của cụm Tivoli SA-MP (trong số các tùy chọn phân cụm khả năng sẵn sàng cao khác, bao gồm cả PowerHA cho AIX), nhưng cá thể cơ sở dữ liệu không được kích hoạt. Như bạn có thể tưởng tượng, cấu hình dự phòng lạnh không có gì nhiều của một giải pháp về khả năng sẵn sàng, ở chỗ là MTTR sẽ thường là lâu hơn rất nhiều cấu hình dự phòng nóng hoặc ấm; tuy nói như thế, nhưng nó có thể phù hợp với nhu cầu của một số ứng dụng của bạn, và nếu như thế, chi phí của giải pháp này thực sự hấp dẫn trong DB2 9.5 và mới hơn, vì những lý do trình bày ở phần trên của bài viết này. Xem xét khi mua giấy phép cho một máy chủ dự phòng lạnh Máy chủ dự phòng lạnh DB2 không cần phải được mua giấy phép và do đó rõ ràng là không phải xem xét việc mua giấy phép. Một nguyên tắc ngón tay cái để xác định xem một máy chủ dự phòng có thể được phân loại là lạnh hay không là hãy xem liệu cá thể DB2 có được khởi động hay không, tuy nhiên có một số trường hợp ngoại lệ. Ví dụ, nếu bạn lấy ảnh chụp nhanh một máy chủ sản xuất và khởi động máy chủ dự phòng DB2 cho mục đích duy nhất là thực hiện một bản sao lưu và sau đó dừng máy chủ lại, chúng tôi coi rằng đó là máy chủ dự phòng lạnh và không cần mua giấy phép cho máy chủ này.
Do đó đây là một ví dụ hoàn hảo về việc quy tắc mua giấy phép của một số phiên bản mới nhất trong DB2 giúp bạn tiết kiệm tiền như thế nào và có ai lại không tìm kiếm điều đó trong thời buổi kinh tế eo hẹp này? Hãy giả sử bạn đang mua giấy phép máy chủ DB2 Workgroup 9 cùng với gói tính năng pureXML cho ứng dụng dựa trên XML với một số yêu cầu về khả năng sẵn sàng cao. Trong DB2 9, bạn phải mua giấy phép đầy đủ cho máy chủ nóng (như dự kiến) cho cả DB2 và gói tính năng của pureXML, ngoài ra, phải mua giấy phép máy chủ lạnh cho 100 PVU của DB2 Workgroup và 100 PVU của gói tính năng của pureXML. Trong DB2 9.7, bạn chỉ cần mua giấy phép DB2Workgroup cho máy chủ nóng. Các tính năng của pureXML được miễn phí trong tất cả các ấn bản của DB2 (từ 09 tháng 2 năm 2009) và máy chủ dự phòng lạnh không yêu cầu phải mua giấy phép. Bây giờ thêm vào thực tế là bạn có thể mua giấy phép SOCKET cho DB2Workgroup, và bạn đã tăng gấp đôi khả năng giải pháp sẵn sàng cao dựa trên XML của bạn và giảm chi phí của mình trên 50%! Về đầu trang Vươn lên cao hơn - khả năng sẵn sàng là như thế Như bạn thấy, bạn có rất nhiều tùy chọn khả năng sẵn sàng cao với DB2. Chúng tôi khuyến nghị khách hàng tạo ra phân loại nhiều tầng cho các ứng dụng yêu cầu khả năng sẵn sàng cao; ví dụ: Xếp hạng đồng, bạc và vàng. Đó có thể sẽ là, bất cứ thứ gì được xếp hạng Đồng sẽ sử dụng máy chủ dự phòng lạnh và cụm được tích hợp của DB2, trong khi giải pháp hạng Bạc sử dụng công nghệ HADR của DB2, và cuối cùng, giải pháp hạng Vàng sẽ là một cấu hình dự phòng nóng chẳng hạn như DB2 pureScale. Chúng tôi đã xếp cạnh nhau thành một bản các giải pháp có thể về khả năng sẵn sàng cao và phân loại tương ứng của chúng trong bảng 2. Bảng 2. Tiếp cận các yêu cầu khả năng sẵn sàng cao của bạn với giải pháp phân tầng và các công nghệ DB2 tương ứng có sẵn Đồng Bạc Vàng Phân cụm được tích hợp của HADR DB2 pureScale DB2  Nóng/ấm (Nóng tùy  Nóng/nóng chọn với đọc ở chế độ  Chuyển đổi dự phòng trực dự phòng)  Nóng/lạnh tuyến  Cung cấp chuyển đổi  Giải pháp khả năng sẵn  Giao dịch trên các nút còn dự phòng rất nhanh, sàng cơ bản hoạt động không bị ảnh thường dưới 1 phút  Miễn phí trong hầu hết hưởng  Dễ dàng cài đặt với các trường hợp  Cung cấp chuyển đổi dự khả năng sẵn sàng chìa  Cung cấp chuyển đổi dự phòng nhanh nhất, thông khóa trao tay phòng, thông thường thường dưới 30 giây  Mua giấy phép tối trong chưa đầy 5 phút  Khả năng dãn nở nhanh thiểu trên máy chủ dự trực tuyến để đáp ứng cao phòng điểm tải công việc  Tùy chọn khả năng mất dữ liệu bằng
không Tại đây chúng tôi muốn lưu ý rằng đây không phải luôn luôn mọi thứ đều cần phải là giải pháp vàng. Mọi người đều nghĩ rằng họ cần khả năng sẵn sàng 24 giờ/ngày 7 ngày/tuần cho tất cả các ứng dụng, nhưng trong kinh nghiệm tư vấn rộng lớn của chúng tôi, không phải là như vậy. Ví dụ: Một khách hàng có một ứng dụng trọng yếu cần phải sẵn sàng 24x7, nhưng các ứng dụng khác của họ có thể bị ngừng chạy đến hai ngày. Trong những trường hợp này, có nên xử lý tất cả như nhau dưới góc nhìn khả năng sẵn sàng? Có lẽ thế nếu bạn có một ngân sách không giới hạn. Hãy chọn giải pháp khả năng sẵn sàng đúng, phù hợp với thỏa thuận cấp độ dịch vụ (SLA) hỗ trợ công việc của bạn: khả năng sẵn sàng cao trong đường cong chi phí tuyến tính. Ngoài phần mềm, bạn muốn khả năng sẵn sàng cao càng nhiều, thì bạn thường phải trả chi phí càng cao (hãy nghĩ đến dư thừa dự phòng, giấy phép, nguồn điện và nhiều thứ nữa). Điểm mấu chốt không phải là tất cả mọi thứ cần phải là cực kỳ sẵn sàng, hãy thông minh và hãy sử dụng đúng công nghệ cho các yêu cầu đúng đắn về khả năng sẵn sàng cao. Mặc dù nằm ngoài phạm vi của bài viết này, để cho đầy đủ, chúng tôi nghĩ rằng chúng tôi sẽ đưa vào thêm bản quy trình Phục hồi sau thảm họa (DR - Disaster Recovery) "người anh em họ" của khả năng sẵn sàng cao trong bảng 3. (Các cân nhắc xem xét tương tự mà bạn sử dụng để xác định mua giấy phép phù hợp cho khả năng sẵn sàng cao cũng áp dụng được cho phục hồi sau thảm họa): Bảng 3. Tiếp cận các yêu cầu phục hồi sau thảm họa của bạn với một giải pháp phân tầng và các công nghệ DB2 tương ứng có sẵn Đồng Bạc Vàng Tạo bản sao Q Tạo bản sao vật lý HADR Tạo bản sao lô-gic HADR  Nóng/nóng  Nóng/nóng  Nóng/ấm  Truy cập không giới hạn  Tùy chọn không mất dữ  Tùy chọn không mất vào cơ sở dữ liệu đích liệu dữ liệu  Hỗ trợ các phiên bản  Chuyển đổi dự phòng trực  Cung cấp chuyển đổi DB2 khác nhau ở dữ tuyến dự phòng rất nhanh, liệu nguồn và đích  Cung cấp chuyển đổi dự thường dưới 1 phút  Hỗ trợ chia tập con dữ phòng nhanh nhất, thông  Dễ cài đặt với khả liệu thường dưới 30 giây năng sẵn sàng chìa  Hỗ trợ nhiều cơ sở dữ  Khả năng dãn nở trực khóa trao tay liệu đích tuyến để đáp ứng cao  Hỗ trợ tạo bản sao  Chuyển đổi dự phòng điểm tải công việc. DDL và DML trực tuyến  Truy cập không giới hạn  Việc sử dụng máy chủ  Có thể tạo bản sao tới đến cơ sở dữ liệu đích dự phòng bị hạn chế một hình trạng khác  Có thể được định cấu hình  Chỉ hỗ trợ một đích dữ  Chỉ phi đồng bộ để áp dụng chậm. liệu  Có thể phức tạp khi thiết  Hỗ trợ nhiều cơ sở dữ liệu  Chỉ tạo bản sao toàn lập đích bộ cơ sở dữ liệu  Không hỗ trợ DDL  Hỗ trợ tạo bản sao DDL và DML