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ả
Trang 1Mua 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
Trang 2cho 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
Trang 3Bả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
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
Trang 4hiệ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
Trang 5HADR, 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
Trang 6sau đó 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
Trang 7trườ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
Trang 8Hì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
Trang 9Cá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
Trang 10Ngoà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
