Này Habr! Tôi trình bày với bạn chú ý bản dịch của bài báo của Andrew Beekhof.
Nhiều người thích cụm hai nút vì chúng có vẻ đơn giản hơn về mặt khái niệm và cũng rẻ hơn 33% so với cụm ba nút. Mặc dù hoàn toàn có thể tập hợp một cụm tốt gồm hai nút, nhưng trong hầu hết các trường hợp, do các tình huống không được xem xét, cấu hình như vậy sẽ tạo ra nhiều vấn đề không rõ ràng.
Bước đầu tiên để tạo ra bất kỳ hệ thống có tính sẵn sàng cao nào là tìm và cố gắng loại bỏ các điểm lỗi riêng lẻ, thường được viết tắt là SPoF (điểm lỗi duy nhất).
Điều đáng lưu ý là không thể loại bỏ tất cả các rủi ro có thể xảy ra về thời gian ngừng hoạt động trong bất kỳ hệ thống nào. Điều này xuất phát từ thực tế là một biện pháp phòng vệ điển hình chống lại rủi ro là đưa ra một số dự phòng, dẫn đến sự phức tạp của hệ thống tăng lên và xuất hiện các điểm thất bại mới. Do đó, ban đầu chúng tôi thỏa hiệp và tập trung vào các sự kiện liên quan đến các điểm lỗi riêng lẻ chứ không phải vào chuỗi các sự kiện liên quan và do đó, ngày càng ít xảy ra hơn.
Với sự đánh đổi, chúng tôi không chỉ tìm kiếm SPoF mà còn cân bằng rủi ro và hậu quả, do đó kết luận điều gì là quan trọng và điều gì không có thể khác nhau đối với mỗi lần triển khai.
Không phải ai cũng cần nhà cung cấp điện thay thế với đường dây điện độc lập. Mặc dù sự hoang tưởng đã được đền đáp cho ít nhất một khách hàng khi bộ phận giám sát của họ phát hiện ra một máy biến áp bị lỗi. Khách hàng đã gọi điện cố gắng báo cho công ty điện lực cho đến khi máy biến áp bị lỗi phát nổ.
Điểm khởi đầu tự nhiên là có nhiều hơn một nút trong hệ thống. Tuy nhiên, trước khi hệ thống có thể di chuyển các dịch vụ đến nút còn tồn tại sau khi xảy ra lỗi, nó thường cần đảm bảo rằng các dịch vụ đang được di chuyển không hoạt động ở nơi khác.
Không có nhược điểm nào đối với cụm hai nút nếu lỗi dẫn đến cả hai nút phục vụ cùng một trang web tĩnh. Tuy nhiên, mọi thứ sẽ thay đổi nếu kết quả là cả hai bên đều quản lý hàng đợi công việc được chia sẻ một cách độc lập hoặc cung cấp quyền truy cập ghi không phối hợp vào cơ sở dữ liệu được sao chép hoặc hệ thống tệp dùng chung.
Do đó, để ngăn chặn dữ liệu bị hỏng do lỗi một nút - chúng tôi dựa vào thứ gọi là "phân ly" (hàng rào).
Nguyên lý phân ly
Trọng tâm của nguyên tắc phân ly là câu hỏi: liệu một nút cạnh tranh có thể gây ra hỏng dữ liệu không? Trong trường hợp có thể xảy ra tình trạng hỏng dữ liệu, giải pháp tốt sẽ là cách ly nút khỏi cả các yêu cầu gửi đến và bộ lưu trữ liên tục. Cách tiếp cận phổ biến nhất để tách liên kết là ngắt kết nối các nút bị lỗi.
Có hai loại phương pháp phân ly mà tôi sẽ gọi là thẳng и gián tiếp, nhưng chúng có thể được gọi như nhau hoạt động и thụ động. Các phương pháp trực tiếp bao gồm các hành động từ phía các đồng nghiệp còn sống, chẳng hạn như tương tác với thiết bị IPMI (Giao diện quản lý nền tảng thông minh) hoặc iLO (cơ chế quản lý máy chủ khi không có quyền truy cập vật lý vào chúng), trong khi các phương pháp gián tiếp dựa vào kết nối không thành công. nút bằng cách nào đó nhận ra rằng nó đang ở trạng thái không tốt (hoặc ít nhất là ngăn các thành viên khác phục hồi) và báo hiệu về sự cần thiết phải ngắt kết nối nút bị lỗi.
Số đại biểu sẽ hữu ích khi sử dụng cả phương pháp trực tiếp và gián tiếp.
Phân ly trực tiếp
Trong trường hợp phân ly trực tiếp, chúng ta có thể sử dụng đại biểu để ngăn chặn các cuộc đua phân ly trong trường hợp mạng bị lỗi.
Với khái niệm về số đại biểu, có đủ thông tin trong hệ thống (ngay cả khi không kết nối với các nút ngang hàng) để các nút tự động biết liệu chúng có nên bắt đầu phân ly và/hoặc phục hồi hay không.
Nếu không có đại biểu, cả hai bên của sự phân chia mạng lưới sẽ cho rằng bên kia đã chết và sẽ tìm cách tách rời bên kia. Trong trường hợp xấu nhất, cả hai bên đều có thể tắt toàn bộ cụm. Một kịch bản thay thế là một trận đấu tử thần, một vòng lặp vô tận của các nút sinh ra, không nhìn thấy các nút ngang hàng của chúng, khởi động lại chúng và chỉ bắt đầu khôi phục để khởi động lại khi nút ngang hàng của chúng tuân theo cùng một logic.
Vấn đề với việc phân tách là các thiết bị được sử dụng phổ biến nhất sẽ không khả dụng do cùng các sự kiện lỗi mà chúng tôi muốn nhắm mục tiêu để khôi phục. Hầu hết các thẻ IPMI và iLO đều được cài đặt trên các máy chủ mà chúng kiểm soát và theo mặc định, sử dụng cùng một mạng, điều này khiến các máy chủ mục tiêu tin rằng các máy chủ khác đang ngoại tuyến.
Thật không may, các tính năng vận hành của thiết bị IPMI và iLo hiếm khi được xem xét tại thời điểm mua thiết bị.
Phân ly gián tiếp
Quorum cũng rất quan trọng để quản lý sự phân ly gián tiếp; nếu thực hiện đúng, Quorum có thể cho phép những người sống sót cho rằng các nút bị mất sẽ chuyển sang trạng thái an toàn sau một khoảng thời gian nhất định.
Với cấu hình này, bộ đếm thời gian giám sát phần cứng được đặt lại sau mỗi N giây nếu đại biểu không bị mất. Nếu bộ hẹn giờ (thường là vài bội số của N) hết hạn, thì thiết bị sẽ thực hiện tắt nguồn một cách vô duyên (không phải tắt máy).
Cách tiếp cận này rất hiệu quả, nhưng nếu không có số đại biểu thì sẽ không có đủ thông tin trong cụm để quản lý nó. Không dễ để phân biệt sự khác biệt giữa sự cố ngừng mạng và lỗi nút ngang hàng. Lý do cho vấn đề này là do không có khả năng phân biệt giữa hai trường hợp, bạn buộc phải chọn hành vi giống nhau trong cả hai trường hợp.
Vấn đề khi chọn một chế độ là không có hành động nào tối đa hóa tính khả dụng và ngăn ngừa mất dữ liệu.
- Nếu bạn chọn giả định rằng một nút ngang hàng đang hoạt động nhưng trên thực tế bị lỗi thì cụm sẽ dừng các dịch vụ đang chạy một cách không cần thiết để bù đắp cho việc mất dịch vụ từ nút ngang hàng bị lỗi.
- Nếu bạn quyết định giả định rằng một nút không hoạt động, nhưng đó chỉ là lỗi mạng và trên thực tế, nút từ xa vẫn hoạt động, thì tốt nhất bạn nên đăng ký một số đối chiếu thủ công trong tương lai đối với các tập dữ liệu kết quả.
Bất kể bạn sử dụng phương pháp heuristic nào, việc tạo ra một lỗi sẽ khiến cả hai bên bị lỗi hoặc khiến cụm đóng các nút còn sống sót là điều không đáng kể. Việc không sử dụng đại biểu thực sự sẽ làm mất đi một trong những công cụ mạnh mẽ nhất trong kho vũ khí của cụm này.
Nếu không có giải pháp thay thế nào khác, cách tiếp cận tốt nhất là hy sinh tính sẵn có (ở đây tác giả đề cập đến định lý CAP). Tính sẵn có cao của dữ liệu bị hỏng không giúp ích được gì cho bất kỳ ai và việc đối chiếu các bộ dữ liệu khác nhau theo cách thủ công cũng không phải là điều thú vị.
đại biểu
Số đại biểu nghe có vẻ tuyệt vời phải không?
Nhược điểm duy nhất là để có nó trong một cụm có N thành viên, bạn cần có kết nối giữa N/2+1 nút còn lại. Điều này là không thể trong cụm hai nút sau khi một nút bị lỗi.
Điều này cuối cùng đưa chúng ta đến vấn đề cơ bản với hai nút:
Số đại biểu không có ý nghĩa trong hai cụm nút và nếu không có nó thì không thể xác định một cách đáng tin cậy quá trình hành động nhằm tối đa hóa tính khả dụng và ngăn ngừa mất dữ liệu
Ngay cả trong một hệ thống gồm hai nút được kết nối bằng cáp chéo, cũng không thể phân biệt rõ ràng giữa sự cố ngừng mạng và lỗi của nút kia. Việc vô hiệu hóa một đầu (tất nhiên xác suất của điều này tỷ lệ thuận với khoảng cách giữa các nút) sẽ đủ để vô hiệu hóa mọi giả định rằng tình trạng của liên kết bằng với tình trạng của nút đối tác.
Làm cho cụm hai nút hoạt động
Đôi khi khách hàng không thể hoặc không muốn mua nút thứ ba và chúng tôi buộc phải tìm kiếm giải pháp thay thế.
Tùy chọn 1 - Phương pháp phân ly trùng lặp
Thiết bị iLO hoặc IPMI của nút đại diện cho một điểm lỗi vì nếu nó bị lỗi, những người sống sót không thể sử dụng nó để đưa nút về trạng thái an toàn. Trong một cụm gồm 3 nút trở lên, chúng ta có thể giảm thiểu điều này bằng cách tính toán số đại biểu và sử dụng cơ quan giám sát phần cứng (một cơ chế phân ly gián tiếp, như đã thảo luận trước đó). Trong trường hợp có hai nút, thay vào đó chúng ta phải sử dụng các đơn vị phân phối nguồn mạng (PDU).
Sau khi thất bại, người sống sót trước tiên sẽ cố gắng liên hệ với thiết bị phân tách chính (iLO hoặc IPMI được nhúng). Nếu điều này thành công, quá trình phục hồi sẽ tiếp tục như bình thường. Chỉ khi thiết bị iLO/IPMI bị lỗi thì PDU mới được truy cập; nếu truy cập thành công, quá trình khôi phục có thể tiếp tục.
Đảm bảo đặt PDU trên một mạng khác với lưu lượng cụm, nếu không, một lỗi mạng sẽ chặn quyền truy cập vào cả hai thiết bị phân tách và chặn khôi phục dịch vụ.
Ở đây bạn có thể hỏi - PDU có phải là một điểm lỗi không? Câu trả lời là tất nhiên là như vậy.
Nếu rủi ro này nghiêm trọng đối với bạn thì bạn không đơn độc: kết nối cả hai nút với hai PDU và yêu cầu phần mềm phân cụm sử dụng cả hai khi bật và tắt nút. Cụm hiện vẫn hoạt động nếu một PDU chết và lỗi thứ hai của PDU khác hoặc thiết bị IPMI sẽ được yêu cầu để chặn quá trình khôi phục.
Tùy chọn 2 - Thêm Trọng tài
Trong một số trường hợp, mặc dù phương pháp tách liên kết trùng lặp có thể thực hiện được về mặt kỹ thuật nhưng lại khó khăn về mặt chính trị. Nhiều công ty muốn có sự tách biệt giữa quản trị viên và chủ sở hữu ứng dụng và quản trị viên mạng quan tâm đến bảo mật không phải lúc nào cũng nhiệt tình chia sẻ cài đặt truy cập PDU với bất kỳ ai.
Trong trường hợp này, giải pháp thay thế được đề xuất là tạo một bên thứ ba trung lập có thể bổ sung cho việc tính toán đại biểu.
Trong trường hợp xảy ra lỗi, một nút phải có khả năng nhìn thấy sóng của thiết bị ngang hàng hoặc trọng tài của nó để khôi phục dịch vụ. Trọng tài cũng bao gồm chức năng ngắt kết nối nếu cả hai nút có thể nhìn thấy trọng tài nhưng không thể nhìn thấy nhau.
Tùy chọn này phải được sử dụng cùng với phương pháp phân tách gián tiếp, chẳng hạn như bộ đếm thời gian theo dõi phần cứng, được cấu hình để tắt máy nếu nó mất kết nối với nút ngang hàng và nút trọng tài. Do đó, một người sống sót có thể giả định một cách hợp lý rằng nút ngang hàng của nó sẽ ở trạng thái an toàn sau khi bộ đếm thời gian theo dõi phần cứng hết hạn.
Sự khác biệt thực tế giữa trọng tài và nút thứ ba là trọng tài yêu cầu ít tài nguyên hơn để hoạt động và có khả năng phục vụ nhiều hơn một cụm.
Phương án 3 - Yếu tố con người
Cách tiếp cận cuối cùng là để những người sống sót tiếp tục chạy bất kỳ dịch vụ nào họ đang chạy, nhưng không bắt đầu các dịch vụ mới cho đến khi sự cố tự giải quyết (khôi phục mạng, khởi động lại nút) hoặc một người chịu trách nhiệm xác nhận thủ công rằng bên kia đã chết.
Tùy chọn tiền thưởng
Tôi đã đề cập đến việc bạn có thể thêm nút thứ ba chưa?
Hai giá đỡ
Để tranh luận, hãy giả sử rằng tôi đã thuyết phục bạn về giá trị của nút thứ ba, bây giờ chúng ta phải xem xét cách sắp xếp vật lý của các nút. Nếu chúng được đặt (và cấp nguồn) trong cùng một giá, điều này cũng tạo thành SPoF và vấn đề không thể giải quyết bằng cách thêm giá thứ hai.
Nếu điều này gây ngạc nhiên, hãy xem xét điều gì sẽ xảy ra nếu một giá đỡ có hai nút bị lỗi và nút còn sống sót sẽ phân biệt như thế nào giữa lỗi đó và lỗi mạng.
Câu trả lời ngắn gọn là điều đó là không thể và một lần nữa chúng ta đang giải quyết tất cả các vấn đề trong trường hợp hai nút. Hoặc người sống sót:
- bỏ qua số đại biểu và các nỗ lực không chính xác để bắt đầu khôi phục trong thời gian ngừng hoạt động của mạng (khả năng phân ly hoàn toàn là một câu chuyện khác và phụ thuộc vào việc PDU có liên quan hay không và liệu chúng có chia sẻ nguồn điện với bất kỳ giá đỡ nào hay không), hoặc
- tôn trọng số đại biểu và tự ngắt kết nối sớm khi nút ngang hàng của nó bị lỗi
Trong mọi trường hợp, hai giá đỡ không tốt hơn một giá đỡ và các nút phải nhận được nguồn điện độc lập hoặc được phân phối trên ba giá đỡ (hoặc nhiều hơn, tùy thuộc vào số lượng nút bạn có).
Hai trung tâm dữ liệu
Tại thời điểm này, những độc giả không còn sợ rủi ro có thể muốn xem xét việc khắc phục thảm họa. Điều gì xảy ra khi một tiểu hành tinh va vào cùng một trung tâm dữ liệu với ba nút của chúng ta trải rộng trên ba giá đỡ khác nhau? Rõ ràng là Những điều tồi tệ, nhưng tùy thuộc vào nhu cầu của bạn, việc thêm một trung tâm dữ liệu thứ hai có thể là không đủ.
Nếu thực hiện đúng, trung tâm dữ liệu thứ hai sẽ cung cấp cho bạn (và hợp lý) bản sao cập nhật và nhất quán về các dịch vụ của bạn cũng như dữ liệu của chúng. Tuy nhiên, giống như trong các kịch bản hai nút, hai giá, hệ thống không có đủ thông tin để đảm bảo tính khả dụng tối đa và ngăn ngừa lỗi (hoặc sai lệch trong tập dữ liệu). Ngay cả với ba nút (hoặc giá đỡ), việc chỉ phân phối chúng trên hai trung tâm dữ liệu khiến hệ thống không thể đưa ra quyết định đúng đắn một cách đáng tin cậy trong trường hợp xảy ra sự kiện (hiện có nhiều khả năng xảy ra) mà cả hai bên không thể liên lạc.
Điều này không có nghĩa là giải pháp trung tâm dữ liệu kép không bao giờ phù hợp. Các công ty thường muốn mọi người biết trước khi thực hiện bước đặc biệt là chuyển sang trung tâm dữ liệu dự phòng. Chỉ cần lưu ý rằng nếu bạn muốn tự động hóa việc ngừng hoạt động, bạn sẽ cần một trung tâm dữ liệu thứ ba để đảm bảo số đại biểu hợp lý (trực tiếp hoặc thông qua trọng tài) hoặc bạn sẽ tìm cách tắt toàn bộ dữ liệu một cách đáng tin cậy trung tâm.
Nguồn: www.habr.com