Xin chào các độc giả của Habr! Trong bài viết trước, chúng ta đã nói về một phương tiện khắc phục thảm họa đơn giản trong hệ thống lưu trữ AERODISK ENGINE - sao chép. Trong bài viết này, chúng ta sẽ đi sâu vào một chủ đề phức tạp và thú vị hơn - metrocluster, tức là một phương tiện bảo vệ thảm họa tự động cho hai trung tâm dữ liệu, cho phép các trung tâm dữ liệu hoạt động ở chế độ tích cực-hoạt động. Chúng tôi sẽ nói với bạn, chỉ cho bạn, phá vỡ nó và sửa chữa nó.
Như thường lệ, lý thuyết đầu tiên
Metrocluster là một cụm trải rộng trên nhiều địa điểm trong một thành phố hoặc khu vực. Từ “cụm” gợi ý rõ ràng cho chúng ta rằng tổ hợp được tự động hóa, nghĩa là việc chuyển đổi các nút cụm trong trường hợp có lỗi xảy ra tự động.
Đây là điểm khác biệt chính giữa metrocluster và bản sao thông thường. Tự động hóa các hoạt động. Nghĩa là, trong trường hợp xảy ra một số sự cố nhất định (lỗi trung tâm dữ liệu, kênh bị hỏng, v.v.), hệ thống lưu trữ sẽ thực hiện độc lập các hành động cần thiết để duy trì tính khả dụng của dữ liệu. Khi sử dụng bản sao thông thường, những hành động này được quản trị viên thực hiện toàn bộ hoặc một phần theo cách thủ công.
nó làm gì?
Mục tiêu chính mà khách hàng theo đuổi khi sử dụng một số triển khai metrocluster nhất định là giảm thiểu RTO (Mục tiêu về thời gian phục hồi). Tức là giảm thiểu thời gian phục hồi của dịch vụ CNTT sau khi gặp sự cố. Nếu bạn sử dụng bản sao thông thường thì thời gian khôi phục sẽ luôn lâu hơn thời gian khôi phục bằng metrocluster. Tại sao? Rất đơn giản. Quản trị viên phải có mặt tại bàn làm việc của mình và chuyển đổi bản sao theo cách thủ công và metrocluster sẽ tự động thực hiện việc này.
Nếu bạn không có một quản trị viên tận tâm trực, không ngủ, không ăn, không hút thuốc hoặc bị ốm và theo dõi trạng thái của hệ thống lưu trữ 24 giờ một ngày, thì không có cách nào để đảm bảo rằng quản trị viên sẽ có sẵn để chuyển đổi thủ công khi có sự cố.
Theo đó, RTO trong trường hợp không có metrocluster hoặc quản trị viên bất tử cấp 99 của dịch vụ nghĩa vụ quản trị viên sẽ bằng tổng thời gian chuyển đổi của tất cả các hệ thống và khoảng thời gian tối đa mà sau đó quản trị viên được đảm bảo bắt đầu làm việc với hệ thống lưu trữ và các hệ thống liên quan.
Do đó, chúng tôi đi đến kết luận rõ ràng rằng nên sử dụng metrocluster nếu yêu cầu đối với RTO là phút chứ không phải giờ hay ngày. Nghĩa là, trong trường hợp trung tâm dữ liệu gặp sự cố tồi tệ nhất, bộ phận CNTT phải cung cấp thời gian cho doanh nghiệp để khôi phục quyền truy cập vào các dịch vụ CNTT trong vòng vài phút hoặc thậm chí vài giây.
Nó hoạt động như thế nào?
Ở cấp độ thấp hơn, metrocluster sử dụng cơ chế sao chép dữ liệu đồng bộ mà chúng tôi đã mô tả trong bài viết trước (xem phần 2). ). Vì quá trình sao chép là đồng bộ nên các yêu cầu đối với nó cũng tương ứng, hay đúng hơn là:
- cáp quang như vật lý, Ethernet 10 gigabit (hoặc cao hơn);
- khoảng cách giữa các trung tâm dữ liệu không quá 40 km;
- độ trễ kênh quang giữa các trung tâm dữ liệu (giữa các hệ thống lưu trữ) lên tới 5 mili giây (tối ưu là 2).
Tất cả các yêu cầu này đều mang tính chất tư vấn, nghĩa là cụm đô thị sẽ hoạt động ngay cả khi các yêu cầu này không được đáp ứng, nhưng chúng ta phải hiểu rằng hậu quả của việc không tuân thủ các yêu cầu này tương đương với việc hoạt động của cả hai hệ thống lưu trữ trong cụm đô thị.
Vì vậy, một bản sao đồng bộ được sử dụng để truyền dữ liệu giữa các hệ thống lưu trữ và làm cách nào để các bản sao tự động chuyển đổi và quan trọng nhất là làm cách nào để tránh bị chia não? Để làm điều này, ở cấp độ cao hơn, một thực thể bổ sung được sử dụng - trọng tài.
Trọng tài làm việc như thế nào và nhiệm vụ của anh ta là gì?
Trọng tài là một máy ảo nhỏ hoặc cụm phần cứng phải được khởi chạy trên trang thứ ba (ví dụ: trong văn phòng) và cung cấp quyền truy cập vào hệ thống lưu trữ thông qua ICMP và SSH. Sau khi khởi chạy, trọng tài phải đặt IP, sau đó từ phía lưu trữ cho biết địa chỉ của nó, cùng với địa chỉ của bộ điều khiển từ xa tham gia vào cụm đô thị. Sau đó, trọng tài đã sẵn sàng làm việc.
Trọng tài liên tục giám sát tất cả các hệ thống lưu trữ trong metrocluster và nếu một hệ thống lưu trữ cụ thể không khả dụng, sau khi xác nhận tính không khả dụng từ một thành viên khác của cụm (một trong những hệ thống lưu trữ “trực tiếp”), trọng tài quyết định khởi chạy quy trình chuyển đổi quy tắc sao chép và lập bản đồ.
Một điểm rất quan trọng. Trọng tài phải luôn ở một địa điểm khác với địa điểm đặt hệ thống lưu trữ, nghĩa là không phải ở trung tâm dữ liệu 1, nơi lắp đặt hệ thống lưu trữ 1, cũng như không ở trung tâm dữ liệu 2, nơi lắp đặt hệ thống lưu trữ 2.
Tại sao? Bởi vì đây là cách duy nhất mà trọng tài, với sự trợ giúp của một trong những hệ thống lưu trữ còn sót lại, có thể xác định rõ ràng và chính xác sự sụp đổ của bất kỳ địa điểm nào trong hai địa điểm nơi hệ thống lưu trữ được lắp đặt. Bất kỳ phương pháp đặt trọng tài nào khác đều có thể dẫn đến tình trạng chia đôi não.
Bây giờ chúng ta hãy đi sâu vào chi tiết công việc của trọng tài.
Trọng tài chạy một số dịch vụ liên tục thăm dò tất cả các bộ điều khiển lưu trữ. Nếu kết quả cuộc thăm dò khác với kết quả trước đó (có sẵn/không có sẵn) thì kết quả đó sẽ được ghi lại trong một cơ sở dữ liệu nhỏ, cơ sở dữ liệu này cũng hoạt động trên trọng tài.
Chúng ta hãy xem xét logic công việc của trọng tài một cách chi tiết hơn.
Bước 1: Xác định tình trạng không sẵn sàng. Sự kiện lỗi hệ thống lưu trữ là việc không có ping từ cả hai bộ điều khiển của cùng một hệ thống lưu trữ trong vòng 5 giây.
Bước 2. Bắt đầu quy trình chuyển đổi. Sau khi trọng tài nhận ra rằng một trong các hệ thống lưu trữ không còn khả dụng, trọng tài sẽ gửi yêu cầu đến hệ thống lưu trữ “đang hoạt động” để đảm bảo rằng hệ thống lưu trữ “đã chết” thực sự đã chết.
Sau khi nhận được lệnh như vậy từ trọng tài, hệ thống lưu trữ thứ hai (trực tiếp) sẽ kiểm tra thêm tính khả dụng của hệ thống lưu trữ thứ nhất bị hỏng và nếu không có ở đó sẽ gửi xác nhận cho trọng tài về dự đoán của anh ta. Hệ thống lưu trữ thực sự không có sẵn.
Sau khi nhận được xác nhận như vậy, trọng tài sẽ khởi chạy một quy trình từ xa để chuyển đổi bản sao và nâng cao ánh xạ trên các bản sao đang hoạt động (chính) trên hệ thống lưu trữ bị hỏng và gửi lệnh đến hệ thống lưu trữ thứ hai để thay đổi các bản sao này từ thứ cấp sang chính và nâng cao bản đồ. Vâng, hệ thống lưu trữ thứ hai, theo đó, thực hiện các quy trình này và sau đó cung cấp quyền truy cập vào các LUN bị mất từ chính nó.
Tại sao cần xác minh bổ sung? Đối với đại biểu. Nghĩa là, phần lớn trong tổng số (3) thành viên cụm lẻ phải xác nhận sự sụp đổ của một trong các nút cụm. Chỉ khi đó quyết định này mới chắc chắn đúng đắn. Điều này là cần thiết để tránh chuyển đổi sai lầm và do đó gây ra hiện tượng chia não.
Thời gian bước 2 mất khoảng 5 - 10 giây, do đó, tính đến thời gian cần thiết để xác định tình trạng không sẵn sàng (5 giây), trong vòng 10 - 15 giây sau khi xảy ra sự cố, LUN từ hệ thống lưu trữ bị hỏng sẽ tự động có sẵn để hoạt động với sự cố. hệ thống lưu trữ.
Rõ ràng là để tránh mất kết nối với máy chủ, bạn cũng cần chú ý cấu hình chính xác thời gian chờ trên máy chủ. Thời gian chờ khuyến nghị ít nhất là 30 giây. Điều này sẽ ngăn máy chủ cắt kết nối với hệ thống lưu trữ trong quá trình chuyển đổi tải trong trường hợp xảy ra thảm họa và có thể đảm bảo rằng không có gián đoạn I/O.
Đợi một chút, hóa ra nếu mọi thứ đều tốt với metrocluster thì tại sao chúng ta lại cần sao chép thường xuyên?
Trong thực tế, mọi thứ không đơn giản như vậy.
Hãy xem xét ưu và nhược điểm của metrocluster
Vì vậy, chúng tôi nhận ra rằng những lợi thế rõ ràng của metrocluster so với sao chép thông thường là:
- Tự động hóa hoàn toàn, đảm bảo thời gian phục hồi tối thiểu trong trường hợp xảy ra thảm họa;
- Đó là tất cả :-).
Và bây giờ, hãy chú ý, nhược điểm:
- Chi phí giải pháp. Mặc dù metrocluster trong hệ thống Aerodisk không yêu cầu cấp phép bổ sung (giấy phép tương tự được sử dụng cho bản sao), nhưng chi phí của giải pháp sẽ vẫn cao hơn so với sử dụng bản sao đồng bộ. Bạn sẽ cần triển khai tất cả các yêu cầu đối với một bản sao đồng bộ, cộng với các yêu cầu đối với cụm đô thị liên quan đến việc chuyển mạch bổ sung và địa điểm bổ sung (xem quy hoạch cụm đô thị);
- Sự phức tạp của giải pháp. Metrocluster phức tạp hơn nhiều so với bản sao thông thường và đòi hỏi nhiều sự chú ý và nỗ lực hơn trong việc lập kế hoạch, cấu hình và lập tài liệu.
Sau cùng. Metrocluster chắc chắn là một giải pháp tốt và có công nghệ tiên tiến khi bạn thực sự cần cung cấp RTO trong vài giây hoặc vài phút. Nhưng nếu không có nhiệm vụ như vậy và RTO trong vài giờ là ổn cho hoạt động kinh doanh, thì việc bắn chim sẻ từ súng đại bác cũng chẳng ích gì. Sự nhân rộng công nhân-nông dân thông thường là đủ, vì một cụm tàu điện ngầm sẽ gây ra thêm chi phí và sự phức tạp của cơ sở hạ tầng CNTT.
Quy hoạch cụm đô thị
Phần này không được coi là hướng dẫn toàn diện về thiết kế metrocluster mà chỉ trình bày các hướng chính cần thực hiện nếu bạn quyết định xây dựng một hệ thống như vậy. Do đó, khi thực sự triển khai metrocluster, hãy đảm bảo có sự tham gia của nhà sản xuất hệ thống lưu trữ (tức là chúng tôi) và các hệ thống liên quan khác để được tư vấn.
địa điểm
Như đã nêu ở trên, một metrocluster yêu cầu tối thiểu ba địa điểm. Hai trung tâm dữ liệu nơi hệ thống lưu trữ và các hệ thống liên quan sẽ hoạt động, cũng như địa điểm thứ ba nơi trọng tài sẽ làm việc.
Khoảng cách được khuyến nghị giữa các trung tâm dữ liệu là không quá 40 km. Khoảng cách lớn hơn rất có thể gây ra sự chậm trễ bổ sung, điều này cực kỳ không mong muốn trong trường hợp của một cụm đô thị lớn. Hãy để chúng tôi nhắc bạn rằng độ trễ phải lên tới 5 mili giây, mặc dù vậy nên giữ chúng trong vòng 2.
Nên kiểm tra sự chậm trễ trong quá trình lập kế hoạch. Bất kỳ nhà cung cấp nào ít nhiều trưởng thành cung cấp cáp quang giữa các trung tâm dữ liệu đều có thể tổ chức kiểm tra chất lượng khá nhanh chóng.
Đối với độ trễ trước trọng tài (nghĩa là giữa trang thứ ba và hai trang đầu tiên), ngưỡng độ trễ được đề xuất lên tới 200 mili giây, tức là kết nối VPN công ty thông thường qua Internet là phù hợp.
Chuyển mạch và kết nối mạng
Không giống như sơ đồ sao chép, nơi chỉ cần kết nối các hệ thống lưu trữ từ các địa điểm khác nhau là đủ, sơ đồ cụm đô thị yêu cầu kết nối các máy chủ với cả hai hệ thống lưu trữ tại các địa điểm khác nhau. Để làm rõ hơn sự khác biệt là gì, cả hai sơ đồ đều được hiển thị bên dưới.
Như có thể thấy từ sơ đồ, máy chủ trang 1 của chúng tôi xem xét cả hệ thống lưu trữ 1 và hệ thống lưu trữ 2. Ngược lại, máy chủ trang 2 xem xét cả hệ thống lưu trữ 2 và hệ thống lưu trữ 1. Nghĩa là, mỗi máy chủ đều nhìn thấy cả hai hệ thống lưu trữ. Đây là điều kiện tiên quyết cho hoạt động của cụm đô thị.
Tất nhiên, không cần thiết phải kết nối từng máy chủ bằng dây quang với một trung tâm dữ liệu khác; không cần cổng hoặc dây là đủ. Tất cả các kết nối này phải được thực hiện thông qua bộ chuyển mạch Ethernet 10G+ hoặc FibreChannel 8G+ (FC chỉ để kết nối máy chủ và hệ thống lưu trữ cho IO, kênh sao chép hiện chỉ khả dụng qua IP (Ethernet 10G+).
Bây giờ là một vài lời về cấu trúc liên kết mạng. Một điểm quan trọng là cấu hình chính xác của mạng con. Cần xác định ngay một số mạng con cho các loại lưu lượng sau:
- Mạng con sao chép mà dữ liệu sẽ được đồng bộ hóa giữa các hệ thống lưu trữ. Có thể có một vài trong số chúng, trong trường hợp này không thành vấn đề, tất cả phụ thuộc vào cấu trúc liên kết mạng hiện tại (đã được triển khai). Nếu có hai trong số chúng thì rõ ràng việc định tuyến phải được cấu hình giữa chúng;
- Mạng con lưu trữ thông qua đó máy chủ sẽ truy cập tài nguyên lưu trữ (nếu là iSCSI). Cần có một mạng con như vậy trong mỗi trung tâm dữ liệu;
- Các mạng con kiểm soát, tức là ba mạng con có thể định tuyến trên ba địa điểm mà hệ thống lưu trữ được quản lý và trọng tài cũng được đặt ở đó.
Chúng tôi không xem xét các mạng con để truy cập tài nguyên máy chủ ở đây vì chúng phụ thuộc nhiều vào các tác vụ.
Việc tách các lưu lượng khác nhau thành các mạng con khác nhau là cực kỳ quan trọng (điều đặc biệt quan trọng là tách bản sao khỏi I/O), bởi vì nếu bạn trộn tất cả lưu lượng truy cập vào một mạng con “dày” thì lưu lượng này sẽ không thể quản lý được và trong điều kiện của hai trung tâm dữ liệu, điều này vẫn có thể gây ra các tùy chọn xung đột mạng khác nhau. Chúng tôi sẽ không đi sâu vào vấn đề này trong khuôn khổ bài viết này, vì bạn có thể đọc về cách lập kế hoạch mạng trải dài giữa các trung tâm dữ liệu trên tài nguyên của các nhà sản xuất thiết bị mạng, nơi điều này được mô tả rất chi tiết.
Cấu hình trọng tài
Trọng tài phải cung cấp quyền truy cập vào tất cả các giao diện quản lý của hệ thống lưu trữ thông qua giao thức ICMP và SSH. Bạn cũng nên suy nghĩ về sự an toàn của trọng tài. Có một sắc thái ở đây.
Chuyển đổi dự phòng trọng tài là rất cần thiết nhưng không bắt buộc. Điều gì xảy ra nếu trọng tài lao xe không đúng lúc?
- Hoạt động của metrocluster ở chế độ bình thường sẽ không thay đổi, vì arbtir hoàn toàn không ảnh hưởng đến hoạt động của metrocluster ở chế độ bình thường (nhiệm vụ của nó là chuyển tải kịp thời giữa các trung tâm dữ liệu)
- Hơn nữa, nếu trọng tài vì lý do này hay lý do khác bị ngã và “ngủ quên” trong một tai nạn trong trung tâm dữ liệu, thì sẽ không có việc chuyển đổi nào xảy ra, vì sẽ không có ai đưa ra các lệnh chuyển đổi cần thiết và tổ chức số đại biểu. Trong trường hợp này, metrocluster sẽ chuyển thành một sơ đồ thông thường có bản sao, sơ đồ này sẽ phải được chuyển đổi thủ công khi xảy ra thảm họa, điều này sẽ ảnh hưởng đến RTO.
Điều gì tiếp theo từ điều này? Nếu bạn thực sự cần đảm bảo RTO tối thiểu, bạn cần đảm bảo trọng tài có khả năng chịu lỗi. Có hai lựa chọn cho việc này:
- Khởi chạy một máy ảo với trọng tài trên trình ảo hóa có khả năng chịu lỗi, may mắn thay là tất cả các trình ảo hóa dành cho người lớn đều hỗ trợ khả năng chịu lỗi;
- Nếu ở trang thứ ba (trong văn phòng thông thường), bạn quá lười cài đặt cụm thông thường và không có cụm hypervozor hiện có, thì chúng tôi đã cung cấp phiên bản phần cứng của trọng tài, được làm trong hộp 2U, trong đó có hai cụm thông thường. Máy chủ x-86 hoạt động và có thể tồn tại sau lỗi cục bộ.
Chúng tôi thực sự khuyên bạn nên đảm bảo khả năng chịu lỗi của trọng tài, mặc dù thực tế là metrocluster không cần nó ở chế độ bình thường. Nhưng như cả lý thuyết và thực tế đều cho thấy, nếu bạn xây dựng được một cơ sở hạ tầng thực sự đáng tin cậy để chống chọi với thảm họa thì tốt hơn hết là bạn nên chơi nó một cách an toàn. Tốt hơn là bạn nên bảo vệ bản thân và doanh nghiệp của mình khỏi “luật ý nghĩa”, tức là khỏi sự thất bại của cả trọng tài và một trong những địa điểm đặt hệ thống lưu trữ.
Giải pháp xây dựng
Xem xét các yêu cầu trên, chúng ta có được kiến trúc giải pháp chung sau đây.
LUN nên được phân bổ đều trên hai địa điểm để tránh tình trạng quá tải nghiêm trọng. Đồng thời, khi định cỡ ở cả hai trung tâm dữ liệu, bạn không chỉ nên tăng gấp đôi dung lượng (cần thiết để lưu trữ dữ liệu đồng thời trên hai hệ thống lưu trữ) mà còn tăng gấp đôi hiệu suất trong IOPS và MB/s để ngăn chặn sự xuống cấp của ứng dụng trong trường hợp một trong các trung tâm dữ liệu bị lỗi.
Riêng biệt, chúng tôi lưu ý rằng với cách tiếp cận thích hợp để định cỡ (nghĩa là, với điều kiện là chúng tôi đã cung cấp giới hạn trên thích hợp của IOPS và MB/s, cũng như tài nguyên CPU và RAM cần thiết), nếu một trong các hệ thống lưu trữ trong cụm metro không thành công, hiệu suất sẽ không bị giảm nghiêm trọng trong điều kiện hoạt động tạm thời trên một hệ thống lưu trữ.
Điều này được giải thích là do khi hai trang web hoạt động đồng thời, bản sao đồng bộ sẽ “ngốn” một nửa hiệu suất ghi, vì mỗi giao dịch phải được ghi vào hai hệ thống lưu trữ (tương tự như RAID-1/10). Vì vậy, nếu một trong các hệ thống lưu trữ bị lỗi, ảnh hưởng của việc sao chép tạm thời (cho đến khi hệ thống lưu trữ bị lỗi được khôi phục) sẽ biến mất và chúng tôi nhận được hiệu suất ghi tăng gấp đôi. Sau khi khởi động lại LUN của hệ thống lưu trữ bị lỗi trên hệ thống lưu trữ đang hoạt động, mức tăng gấp đôi này sẽ biến mất do tải xuất hiện từ LUN của hệ thống lưu trữ khác và chúng tôi quay trở lại mức hiệu suất tương tự như trước đó. “rơi”, nhưng chỉ trong khuôn khổ một trang web.
Với sự trợ giúp của việc định cỡ phù hợp, bạn có thể đảm bảo các điều kiện mà theo đó người dùng sẽ không cảm thấy toàn bộ hệ thống lưu trữ bị lỗi. Nhưng chúng tôi nhắc lại một lần nữa, điều này đòi hỏi phải xác định kích thước rất cẩn thận, nhân tiện, bạn có thể liên hệ miễn phí với chúng tôi :-).
Thiết lập một metrocluster
Việc thiết lập một metrocluster rất giống với việc thiết lập bản sao thông thường mà chúng tôi đã mô tả trong . Vì vậy, chúng ta hãy chỉ tập trung vào sự khác biệt. Chúng tôi thiết lập một băng ghế trong phòng thí nghiệm dựa trên kiến trúc ở trên, chỉ ở phiên bản tối thiểu: hai hệ thống lưu trữ được kết nối qua Ethernet 10G, hai bộ chuyển mạch 10G và một máy chủ nhìn qua các bộ chuyển mạch ở cả hai hệ thống lưu trữ có cổng 10G. Trọng tài chạy trên máy ảo.
Khi định cấu hình IP ảo (VIP) cho bản sao, bạn nên chọn loại VIP - dành cho metrocluster.
Chúng tôi đã tạo hai liên kết sao chép cho hai LUN và phân phối chúng trên hai hệ thống lưu trữ: LUN TEST Primary trên hệ thống lưu trữ 1 (liên kết METRO), LUN TEST2 Primary cho hệ thống lưu trữ 2 (liên kết METRO2).
Đối với họ, chúng tôi đã định cấu hình hai mục tiêu giống hệt nhau (trong trường hợp của chúng tôi là iSCSI, nhưng FC cũng được hỗ trợ, logic thiết lập giống nhau).
Hệ thống lưu trữ1:
Hệ thống lưu trữ2:
Đối với các kết nối nhân rộng, ánh xạ được thực hiện trên mỗi hệ thống lưu trữ.
Hệ thống lưu trữ1:
Hệ thống lưu trữ2:
Chúng tôi thiết lập đa đường và trình bày nó với máy chủ.
Thành lập trọng tài
Bạn không cần phải làm bất cứ điều gì đặc biệt với chính trọng tài; bạn chỉ cần kích hoạt nó trên trang web thứ ba, cấp cho nó một IP và định cấu hình quyền truy cập vào nó thông qua ICMP và SSH. Bản thân việc thiết lập được thực hiện từ chính hệ thống lưu trữ. Trong trường hợp này, chỉ cần định cấu hình trọng tài một lần trên bất kỳ bộ điều khiển lưu trữ nào trong cụm đô thị là đủ; các cài đặt này sẽ được phân phối tự động đến tất cả các bộ điều khiển.
Trong phần Sao chép từ xa>> Metrocluster (trên bất kỳ bộ điều khiển nào)>> nút “Cấu hình”.
Chúng tôi nhập IP của trọng tài, cũng như giao diện điều khiển của hai bộ điều khiển lưu trữ từ xa.
Sau đó, bạn cần kích hoạt tất cả các dịch vụ (nút “Khởi động lại mọi thứ”). Nếu được cấu hình lại trong tương lai, các dịch vụ phải được khởi động lại để cài đặt có hiệu lực.
Chúng tôi kiểm tra xem tất cả các dịch vụ có đang chạy không.
Điều này hoàn tất việc thiết lập metrocluster.
Kiểm tra sự cố
Thử nghiệm sự cố trong trường hợp của chúng tôi sẽ khá đơn giản và nhanh chóng vì chức năng sao chép (chuyển đổi, tính nhất quán, v.v.) đã được thảo luận trong . Do đó, để kiểm tra độ tin cậy của metrocluster, việc chúng tôi kiểm tra tính năng tự động hóa phát hiện lỗi, chuyển mạch và không ghi lại tổn thất (dừng I/O) là đủ.
Để thực hiện việc này, chúng tôi mô phỏng lỗi hoàn toàn của một trong các hệ thống lưu trữ bằng cách tắt vật lý cả hai bộ điều khiển của nó, sau khi bắt đầu sao chép một tệp lớn sang LUN, tệp này phải được kích hoạt trên hệ thống lưu trữ khác.
Vô hiệu hóa một hệ thống lưu trữ. Trên hệ thống lưu trữ thứ hai, chúng tôi thấy các cảnh báo và thông báo trong nhật ký cho biết kết nối với hệ thống lân cận đã bị mất. Nếu thông báo qua giám sát SMTP hoặc SNMP được định cấu hình, quản trị viên sẽ nhận được thông báo tương ứng.
Chính xác 10 giây sau (hiển thị trong cả hai ảnh chụp màn hình), kết nối sao chép METRO (kết nối Chính trên hệ thống lưu trữ bị lỗi) tự động trở thành Chính trên hệ thống lưu trữ đang hoạt động. Bằng cách sử dụng ánh xạ hiện có, LUN TEST vẫn có sẵn trên máy chủ, quá trình ghi giảm đi một chút (trong khoảng 10% đã hứa) nhưng không bị gián đoạn.
Cuộc thử nghiệm đã hoàn tất thành công.
Tổng kết
Việc triển khai metrocluster hiện tại trong các hệ thống lưu trữ dòng N của AERODISK Engine hoàn toàn cho phép giải quyết các vấn đề cần loại bỏ hoặc giảm thiểu thời gian ngừng hoạt động của các dịch vụ CNTT và đảm bảo chúng hoạt động 24/7/365 với chi phí lao động tối thiểu.
Tất nhiên, chúng tôi có thể nói rằng tất cả những điều này chỉ là lý thuyết, điều kiện phòng thí nghiệm lý tưởng, v.v. NHƯNG chúng tôi có một số dự án đã triển khai trong đó chúng tôi đã triển khai chức năng chống chịu thảm họa và các hệ thống hoạt động hoàn hảo. Một trong những khách hàng khá nổi tiếng của chúng tôi, những người chỉ sử dụng hai hệ thống lưu trữ trong cấu hình chống thảm họa, đã đồng ý công bố thông tin về dự án, vì vậy trong phần tiếp theo chúng tôi sẽ nói về việc triển khai chiến đấu.
Cảm ơn bạn, chúng tôi mong muốn có một cuộc thảo luận hiệu quả.
Nguồn: www.habr.com