Định lý CAP là nền tảng của lý thuyết hệ thống phân tán. Tất nhiên, những tranh cãi xung quanh nó không hề lắng xuống: các định nghĩa trong đó không mang tính kinh điển và không có bằng chứng chặt chẽ nào... Tuy nhiên, đứng vững trên quan điểm của lẽ thường hàng ngày™, chúng tôi hiểu bằng trực giác rằng định lý này là đúng.
Điều duy nhất không rõ ràng là ý nghĩa của chữ "P". Khi cụm được chia, nó sẽ quyết định không phản hồi cho đến khi đạt được số đại biểu hoặc trả lại dữ liệu có sẵn. Tùy thuộc vào kết quả của sự lựa chọn này, hệ thống được phân loại thành CP hoặc AP. Ví dụ, Cassandra có thể hoạt động theo một trong hai cách, thậm chí không phụ thuộc vào cài đặt cụm mà phụ thuộc vào các tham số của từng yêu cầu cụ thể. Nhưng nếu hệ thống không phải là "P" và nó bị tách ra thì sao?
Câu trả lời cho câu hỏi này hơi bất ngờ: một cụm CA không thể phân chia.
Đây là loại cụm nào không thể phân chia?
Một thuộc tính không thể thiếu của cụm như vậy là hệ thống lưu trữ dữ liệu dùng chung. Trong phần lớn các trường hợp, điều này có nghĩa là kết nối qua SAN, điều này hạn chế việc sử dụng giải pháp CA cho các doanh nghiệp lớn có khả năng duy trì cơ sở hạ tầng SAN. Để nhiều máy chủ hoạt động với cùng một dữ liệu, cần có một hệ thống tệp được phân cụm. Các hệ thống tệp như vậy có sẵn trong danh mục HPE (CFS), Veritas (VxCFS) và IBM (GPFS).
Oracle RAC
Tùy chọn Cụm ứng dụng thực xuất hiện lần đầu tiên vào năm 2001 với việc phát hành Oracle 9i. Trong một cụm như vậy, một số phiên bản máy chủ hoạt động với cùng một cơ sở dữ liệu.
Oracle có thể hoạt động với cả hệ thống tệp phân cụm và giải pháp riêng của mình - ASM, Quản lý lưu trữ tự động.
Mỗi bản giữ một tạp chí riêng. Giao dịch được thực hiện và cam kết bởi một phiên bản. Nếu một phiên bản bị lỗi, một trong các nút cụm (phiên bản) còn sót lại sẽ đọc nhật ký của nó và khôi phục dữ liệu bị mất - từ đó đảm bảo tính khả dụng.
Tất cả các phiên bản đều duy trì bộ đệm riêng và các trang (khối) giống nhau có thể nằm trong bộ đệm của nhiều phiên bản cùng một lúc. Hơn nữa, nếu một phiên bản cần một trang và trang đó nằm trong bộ đệm của một phiên bản khác, thì nó có thể lấy trang đó từ phiên bản lân cận bằng cách sử dụng cơ chế tổng hợp bộ đệm thay vì đọc từ đĩa.
Nhưng điều gì sẽ xảy ra nếu một trong các trường hợp cần thay đổi dữ liệu?
Điểm đặc biệt của Oracle là nó không có dịch vụ khóa chuyên dụng: nếu máy chủ muốn khóa một hàng thì bản ghi khóa sẽ được đặt trực tiếp trên trang bộ nhớ nơi đặt hàng bị khóa. Nhờ cách tiếp cận này, Oracle là nhà vô địch về hiệu suất trong số các cơ sở dữ liệu nguyên khối: dịch vụ khóa không bao giờ trở thành nút cổ chai. Nhưng trong cấu hình cụm, kiến trúc như vậy có thể dẫn đến tình trạng bế tắc và lưu lượng mạng lớn.
Khi một bản ghi bị khóa, một phiên bản sẽ thông báo cho tất cả các phiên bản khác rằng trang lưu trữ bản ghi đó có quyền lưu giữ độc quyền. Nếu một phiên bản khác cần thay đổi một bản ghi trên cùng một trang, nó phải đợi cho đến khi các thay đổi trên trang được cam kết, tức là thông tin thay đổi được ghi vào nhật ký trên đĩa (và giao dịch có thể tiếp tục). Cũng có thể xảy ra trường hợp một trang sẽ được thay đổi tuần tự bởi một số bản sao, và khi ghi trang đó vào đĩa, bạn sẽ phải tìm ra ai lưu trữ phiên bản hiện tại của trang này.
Việc cập nhật ngẫu nhiên các trang giống nhau trên các nút RAC khác nhau khiến hiệu suất cơ sở dữ liệu giảm đáng kể, đến mức hiệu suất của cụm có thể thấp hơn hiệu suất của một phiên bản đơn lẻ.
Cách sử dụng đúng đắn của Oracle RAC là phân vùng dữ liệu một cách vật lý (ví dụ: sử dụng cơ chế bảng được phân vùng) và truy cập từng bộ phân vùng thông qua một nút chuyên dụng. Mục đích chính của RAC không phải là mở rộng quy mô theo chiều ngang mà là đảm bảo khả năng chịu lỗi.
Nếu một nút ngừng phản hồi nhịp tim thì nút phát hiện ra nút đó trước tiên sẽ bắt đầu quy trình biểu quyết trên đĩa. Nếu nút bị thiếu không được ghi chú ở đây thì một trong các nút sẽ chịu trách nhiệm khôi phục dữ liệu:
- “đóng băng” tất cả các trang nằm trong bộ đệm của nút bị thiếu;
- đọc nhật ký (làm lại) của nút bị thiếu và áp dụng lại các thay đổi được ghi trong nhật ký này, đồng thời kiểm tra xem các nút khác có phiên bản mới hơn của trang đang được thay đổi hay không;
- cuộn lại các giao dịch đang chờ xử lý.
Để đơn giản hóa việc chuyển đổi giữa các nút, Oracle có khái niệm về dịch vụ - một phiên bản ảo. Một phiên bản có thể phục vụ nhiều dịch vụ và một dịch vụ có thể di chuyển giữa các nút. Một phiên bản ứng dụng phục vụ một phần nhất định của cơ sở dữ liệu (ví dụ: một nhóm máy khách) hoạt động với một dịch vụ và dịch vụ chịu trách nhiệm về phần cơ sở dữ liệu này sẽ chuyển sang một nút khác khi một nút bị lỗi.
Hệ thống dữ liệu thuần túy của IBM dành cho giao dịch
Một giải pháp cụm cho DBMS đã xuất hiện trong danh mục Blue Giant vào năm 2009. Về mặt ý thức hệ, nó là sự kế thừa của cụm Parallel Sysplex, được xây dựng trên thiết bị “thông thường”. Năm 2009, DB2 pureScale được phát hành dưới dạng một bộ phần mềm và vào năm 2012, IBM đã cung cấp một thiết bị có tên là Hệ thống dữ liệu thuần túy cho các giao dịch. Không nên nhầm lẫn nó với Hệ thống dữ liệu thuần túy cho phân tích, không gì khác hơn là Netezza đã được đổi tên.
Thoạt nhìn, kiến trúc pureScale tương tự như Oracle RAC: theo cách tương tự, một số nút được kết nối với một hệ thống lưu trữ dữ liệu chung và mỗi nút chạy phiên bản DBMS riêng với các vùng bộ nhớ và nhật ký giao dịch riêng. Tuy nhiên, không giống như Oracle, DB2 có một dịch vụ khóa chuyên dụng được biểu thị bằng một tập hợp các quy trình db2LLM*. Trong cấu hình cụm, dịch vụ này được đặt trên một nút riêng biệt, được gọi là phương tiện ghép nối (CF) trong Parallel Sysplex và PowerHA trong Pure Data.
PowerHA cung cấp các dịch vụ sau:
- quản lý khóa;
- bộ đệm đệm toàn cầu;
- lĩnh vực truyền thông giữa các quá trình.
Để truyền dữ liệu từ PowerHA đến các nút cơ sở dữ liệu và ngược lại, quyền truy cập bộ nhớ từ xa được sử dụng, do đó, kết nối cụm phải hỗ trợ giao thức RDMA. PureScale có thể sử dụng cả Infiniband và RDMA qua Ethernet.
Nếu một nút cần một trang và trang này không có trong bộ đệm thì nút đó sẽ yêu cầu trang đó trong bộ đệm chung và chỉ khi nó không có ở đó thì mới đọc nó từ đĩa. Không giống như Oracle, yêu cầu chỉ đến PowerHA chứ không đến các nút lân cận.
Nếu một phiên bản định thay đổi một hàng, nó sẽ khóa hàng đó ở chế độ độc quyền và trang chứa hàng đó ở chế độ chia sẻ. Tất cả các khóa được đăng ký trong trình quản lý khóa toàn cầu. Khi giao dịch hoàn tất, nút sẽ gửi một thông báo đến trình quản lý khóa để sao chép trang đã sửa đổi vào bộ đệm chung, giải phóng các khóa và vô hiệu hóa trang đã sửa đổi trong bộ đệm của các nút khác.
Nếu trang chứa hàng được sửa đổi đã bị khóa thì trình quản lý khóa sẽ đọc trang đã sửa đổi từ bộ nhớ của nút đã thực hiện thay đổi, giải phóng khóa, vô hiệu hóa trang đã sửa đổi trong bộ đệm của các nút khác và cung cấp khóa trang cho nút đã yêu cầu nó.
“Bẩn”, nghĩa là đã thay đổi, các trang có thể được ghi vào đĩa từ cả nút thông thường và từ PowerHA (loại bỏ).
Nếu một trong các nút pureScale không thành công, quá trình khôi phục chỉ được giới hạn ở những giao dịch chưa hoàn thành tại thời điểm xảy ra lỗi: các trang được nút đó sửa đổi trong các giao dịch đã hoàn thành sẽ nằm trong bộ nhớ đệm chung trên PowerHA. Nút khởi động lại ở cấu hình giảm trên một trong các máy chủ trong cụm, khôi phục các giao dịch đang chờ xử lý và giải phóng các khóa.
PowerHA chạy trên hai máy chủ và nút chính sao chép trạng thái của nó một cách đồng bộ. Nếu nút PowerHA chính bị lỗi, cụm sẽ tiếp tục hoạt động với nút dự phòng.
Tất nhiên, nếu bạn truy cập tập dữ liệu thông qua một nút duy nhất thì hiệu suất tổng thể của cụm sẽ cao hơn. PureScale thậm chí có thể nhận thấy rằng một vùng dữ liệu nhất định đang được xử lý bởi một nút và sau đó tất cả các khóa liên quan đến khu vực đó sẽ được nút xử lý cục bộ mà không cần liên lạc với PowerHA. Nhưng ngay khi ứng dụng cố gắng truy cập dữ liệu này thông qua một nút khác, quá trình xử lý khóa tập trung sẽ tiếp tục.
Các thử nghiệm nội bộ của IBM về khối lượng công việc 90% đọc và 10% ghi, rất giống với khối lượng công việc sản xuất trong thế giới thực, cho thấy khả năng mở rộng gần như tuyến tính lên tới 128 nút. Thật không may, điều kiện thử nghiệm không được tiết lộ.
HPE NonStop SQL
Danh mục Hewlett-Packard Enterprise cũng có nền tảng có tính sẵn sàng cao của riêng mình. Đây là nền tảng NonStop, được Tandem Computers tung ra thị trường vào năm 1976. Năm 1997, công ty được Compaq mua lại, sau đó sáp nhập với Hewlett-Packard vào năm 2002.
NonStop được sử dụng để xây dựng các ứng dụng quan trọng - ví dụ: HLR hoặc xử lý thẻ ngân hàng. Nền tảng này được phân phối dưới dạng một tổ hợp phần mềm và phần cứng (thiết bị), bao gồm các nút tính toán, hệ thống lưu trữ dữ liệu và thiết bị liên lạc. Mạng ServerNet (trong các hệ thống hiện đại - Infiniband) phục vụ cả việc trao đổi giữa các nút và truy cập vào hệ thống lưu trữ dữ liệu.
Các phiên bản đầu tiên của hệ thống sử dụng các bộ xử lý độc quyền được đồng bộ hóa với nhau: tất cả các hoạt động được thực hiện đồng bộ bởi một số bộ xử lý và ngay khi một trong các bộ xử lý gặp lỗi, nó sẽ bị tắt và bộ xử lý thứ hai tiếp tục hoạt động. Sau đó, hệ thống chuyển sang bộ xử lý thông thường (MIPS đầu tiên, sau đó là Itanium và cuối cùng là x86) và các cơ chế khác bắt đầu được sử dụng để đồng bộ hóa:
- tin nhắn: mỗi quy trình hệ thống có một bản song sinh "bóng", trong đó quy trình hoạt động sẽ gửi tin nhắn định kỳ về trạng thái của nó; nếu quy trình chính không thành công, quy trình bóng sẽ bắt đầu hoạt động kể từ thời điểm được xác định bởi thông báo cuối cùng;
- biểu quyết: hệ thống lưu trữ có một thành phần phần cứng đặc biệt chấp nhận nhiều quyền truy cập giống hệt nhau và chỉ thực thi chúng nếu các quyền truy cập khớp nhau; Thay vì đồng bộ hóa vật lý, bộ xử lý hoạt động không đồng bộ và kết quả công việc của chúng chỉ được so sánh tại các thời điểm I/O.
Từ năm 1987, một DBMS quan hệ đã chạy trên nền tảng NonStop - SQL/MP đầu tiên và SQL/MX sau này.
Toàn bộ cơ sở dữ liệu được chia thành các phần và mỗi phần chịu trách nhiệm về quy trình Trình quản lý truy cập dữ liệu (DAM) của riêng mình. Nó cung cấp cơ chế ghi dữ liệu, bộ nhớ đệm và khóa. Việc xử lý dữ liệu được thực hiện bởi các Quy trình máy chủ Executor chạy trên cùng các nút với trình quản lý dữ liệu tương ứng. Bộ lập lịch SQL/MX phân chia nhiệm vụ giữa những người thực thi và tổng hợp kết quả. Khi cần thực hiện các thay đổi đã được thống nhất, giao thức cam kết hai giai đoạn do thư viện TMF (Cơ sở quản lý giao dịch) cung cấp sẽ được sử dụng.
NonStop SQL có thể ưu tiên các quy trình để các truy vấn phân tích dài không cản trở việc thực hiện giao dịch. Tuy nhiên, mục đích của nó chính xác là xử lý các giao dịch ngắn chứ không phải phân tích. Nhà phát triển đảm bảo tính khả dụng của cụm NonStop ở mức năm “chín”, tức là thời gian ngừng hoạt động chỉ 5 phút mỗi năm.
SAP-HANA
Bản phát hành ổn định đầu tiên của HANA DBMS (1.0) diễn ra vào tháng 2010 năm 2013 và gói SAP ERP đã chuyển sang HANA vào tháng XNUMX năm XNUMX. Nền tảng này dựa trên các công nghệ đã mua: Công cụ tìm kiếm TREX (tìm kiếm trong bộ lưu trữ cột), P*TIME DBMS và MAX DB.
Bản thân từ “HANA” là từ viết tắt của Thiết bị phân tích hiệu suất cao. DBMS này được cung cấp dưới dạng mã có thể chạy trên bất kỳ máy chủ x86 nào, tuy nhiên, việc cài đặt công nghiệp chỉ được phép trên thiết bị được chứng nhận. Các giải pháp có sẵn từ HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Một số cấu hình của Lenovo thậm chí còn cho phép hoạt động mà không cần SAN - vai trò của hệ thống lưu trữ chung được thực hiện bởi cụm GPFS trên các đĩa cục bộ.
Không giống như các nền tảng được liệt kê ở trên, HANA là một DBMS trong bộ nhớ, tức là hình ảnh dữ liệu chính được lưu trữ trong RAM và chỉ nhật ký cũng như ảnh chụp nhanh định kỳ được ghi vào đĩa để khôi phục trong trường hợp xảy ra thảm họa.
Mỗi nút cụm HANA chịu trách nhiệm về một phần dữ liệu riêng của mình và bản đồ dữ liệu được lưu trữ trong một thành phần đặc biệt – Máy chủ tên, nằm trên nút điều phối. Dữ liệu không bị trùng lặp giữa các nút. Thông tin khóa cũng được lưu trữ trên mỗi nút, nhưng hệ thống có bộ phát hiện khóa chết toàn cầu.
Khi máy khách HANA kết nối với một cụm, nó sẽ tải cấu trúc liên kết của nó xuống và sau đó có thể truy cập trực tiếp vào bất kỳ nút nào, tùy thuộc vào dữ liệu nó cần. Nếu một giao dịch ảnh hưởng đến dữ liệu của một nút thì nút đó có thể được thực thi cục bộ bởi nút đó, nhưng nếu dữ liệu của một số nút thay đổi, nút khởi tạo sẽ liên hệ với nút điều phối, nút này sẽ mở và điều phối giao dịch phân tán, cam kết nó bằng cách sử dụng một giao thức cam kết hai pha được tối ưu hóa.
Nút điều phối viên bị trùng lặp, vì vậy nếu nút điều phối viên bị lỗi, nút dự phòng sẽ ngay lập tức tiếp quản. Nhưng nếu một nút có dữ liệu bị lỗi thì cách duy nhất để truy cập dữ liệu của nó là khởi động lại nút đó. Theo quy định, các cụm HANA duy trì một máy chủ dự phòng để khởi động lại nút bị mất trên đó càng nhanh càng tốt.
Nguồn: www.habr.com