Kiến trúc cho MySQL có tính sẵn sàng cao với chuyển đổi dự phòng tự động ở các vị trí đa dạng vật lý

Tôi đã nghiên cứu các giải pháp có tính sẵn sàng cao (HA) cho MySQL giữa các trung tâm dữ liệu.

Đối với các máy chủ đặt trong cùng môi trường vật lý, tôi đã ưu tiên sử dụng chủ kép với nhịp tim (VIP nổi) bằng cách sử dụng phương pháp thụ động chủ động. Nhịp tim vượt qua cả kết nối nối tiếp cũng như kết nối ethernet.

Cuối cùng, mục tiêu của tôi là duy trì mức độ sẵn có như vậy nhưng giữa các trung tâm dữ liệu. Tôi muốn tự động chuyển đổi dự phòng giữa cả hai trung tâm dữ liệu mà không cần can thiệp thủ công và vẫn duy trì tính toàn vẹn dữ liệu.

Sẽ có BGP trên đầu trang. Các cụm web ở cả hai vị trí, có khả năng định tuyến đến cơ sở dữ liệu giữa hai bên. Nếu kết nối Internet bị hỏng trên trang 1, khách hàng sẽ định tuyến qua trang 2, đến cụm Web và sau đó đến cơ sở dữ liệu ở trang 1 nếu liên kết giữa cả hai trang vẫn còn.

Với kịch bản này, do thiếu liên kết vật lý (nối tiếp) nên có nhiều khả năng bị tách não. Nếu mạng LAN đi xuống giữa cả hai trang web, VIP sẽ kết thúc trên cả hai trang web, nơi một loạt các kịch bản khó chịu có thể giới thiệu desync.

Một vấn đề tiềm năng khác mà tôi thấy là khó mở rộng cơ sở hạ tầng này đến một trung tâm dữ liệu thứ ba trong tương lai.

Lớp mạng không phải là một trọng tâm. Kiến trúc linh hoạt ở giai đoạn này. Một lần nữa, trọng tâm của tôi là một giải pháp để duy trì tính toàn vẹn dữ liệu cũng như chuyển đổi dự phòng tự động với cơ sở dữ liệu MySQL. Tôi có thể sẽ thiết kế phần còn lại xung quanh này.

Bạn có thể giới thiệu một giải pháp đã được chứng minh cho MySQL HA giữa hai trang web đa dạng về thể chất không?

Cảm ơn bạn đa bỏ thơi gian ra đọc nhưng điêu nay. Tôi mong được đọc các khuyến nghị của bạn.

Bạn sẽ phải đối mặt với vấn đề định lý "CAP". Bạn không thể có tính nhất quán, tính sẵn có và dung sai phân vùng cùng một lúc.

DRBD / MySQL HA dựa trên sao chép đồng bộ ở cấp thiết bị khối. Điều này là tốt trong khi cả hai nút có sẵn, hoặc nếu một lỗi bị lỗi tạm thời, được khởi động lại, vv, sau đó quay trở lại. Các vấn đề bắt đầu khi bạn nhận được một phân vùng mạng.

Phân vùng mạng rất có thể khi bạn đang chạy ở hai trung tâm dữ liệu. Về cơ bản, không bên nào có thể phân biệt một phân vùng với các nút khác bị lỗi. Nút phụ không biết có nên tiếp quản (nút chính đã thất bại) hay không (liên kết đã biến mất).

Trong khi các máy của bạn ở cùng một vị trí, bạn có thể thêm một kênh liên lạc thứ cấp (thường là cáp nối tiếp hoặc ethernet chéo) để khắc phục vấn đề này - vì vậy, thứ cấp biết khi nào thì chính bị lỗi và đó không phải là phân vùng mạng .

Vấn đề tiếp theo là hiệu suất. Mặc dù DRBD có thể mang lại hiệu năng ** tốt khi máy của bạn có kết nối có độ trễ thấp (ví dụ: etherabit gigabit - nhưng một số người sử dụng mạng tốc độ cao chuyên dụng), mạng càng có độ trễ, thời gian thực hiện giao dịch càng lâu. . Điều này là do nó cần đợi máy chủ thứ cấp (khi trực tuyến) xác nhận tất cả các ghi trước khi nói "OK" với ứng dụng để đảm bảo độ bền của ghi.

Nếu bạn làm điều này trong các trung tâm dữ liệu khác nhau, bạn thường có độ trễ vài mili giây hơn, ngay cả khi chúng ở gần.

** Vẫn chậm hơn nhiều so với bộ điều khiển IO cục bộ

*** Bạn không thể sử dụng MyISAM cho hệ thống DRBD khả dụng cao vì nó không phục hồi đúng cách / tự động sau khi tắt máy không sạch, được yêu cầu trong quá trình chuyển đổi dự phòng.

Điều gì về việc sử dụng Vlan để liên kết tất cả các máy chủ tại hai (hoặc nhiều) trung tâm dữ liệu lại với nhau. Sau đó, bạn có thể sử dụng CARP để chuyển đổi dự phòng tự động. Sử dụng sao chép cơ sở dữ liệu để giữ mọi thứ đồng bộ.

Nếu bạn sở hữu các trung tâm dữ liệu, bạn có thể đảm bảo mỗi trung tâm dữ liệu có nhiều đường lên mạng WAN.

Giai đoạn đầu tiên của bạn là nâng cấp giải pháp HA hiện tại của bạn lên giải pháp sử dụng OpenAIS làm lớp thành viên Cluster: điều này sẽ mang lại cho bạn rất nhiều tính linh hoạt và cung cấp các liên kết có độ trễ thấp giữa các trang web, có thể có thể tiếp cận. PaceMaker và RHEL Clustering hỗ trợ điều này.

Đối với chuyển đổi dự phòng trung tâm dữ liệu tự động, bạn thực sự cần một trang web thứ ba để hoạt động như một bộ ngắt kết nối, nếu không các trang web của bạn sẽ không thể phân biệt giữa các sự cố định tuyến giữa các trang web và lỗi trang web từ xa. Microsoft có một số trang web tốt đáng ngạc nhiên bao gồm khu vực:

Phân cụm nhiều trang Windows Server 2008

Rõ ràng công nghệ chính xác không ánh xạ vào miền Linux, nhưng các khái niệm là như nhau.

Xin lỗi, đây là một mạng khác, nhưng một ý nghĩ cho ...

Đối với kịch bản phân chia não bạn đã đề cập, bạn có thể có các liên kết dự phòng giữa hai trang web để giảm khả năng điều này xảy ra.

Lưu ý rằng bạn có thể không thể sử dụng BGP, vì khối có thể định tuyến nhỏ nhất là 4k, a / 22, chúc may mắn nhận được một. Có lẽ một giải pháp dựa trên DNS là cần thiết.

Đưa ra một câu trả lời chính xác có thể khó tùy thuộc vào lượng dữ liệu bạn có, số lượng máy chủ bạn muốn phù hợp với điều này, v.v. Điều đó có thể nói, câu trả lời của tôi có thể không phải là một, hoặc ít nhất là bạn đang tìm kiếm.

Không có giải pháp đã được chứng minh cho nhiều trang web với MySQL. Nhưng có giải pháp hoạt động. Như một số chỉ ra, có DRDB hoạt động tốt nhưng có giới hạn hoặc vấn đề có thể xảy ra tùy thuộc vào thiết lập của bạn.

Bạn có bao giờ cần một trang web thứ ba (một trung tâm dữ liệu khác) không? Nếu vậy, bạn sẽ phải mất bao nhiêu thời gian và tiền bạc để làm việc này?

Xem xét mỗi khi bạn thêm máy chủ chính / nô lệ / dns, sao lưu, ... bạn thêm cho mình một máy chủ để quản lý, năng lực quản lý của bạn về số lượng máy chủ là bao nhiêu? Nếu bạn có thể xác định số này, bạn có thể phải loại bỏ một số giải pháp có thể và hướng tới những giải pháp phù hợp với số của bạn để việc quản lý không trở thành nút cổ chai.

Xem xét các trung tâm dữ liệu không đi xuống thường xuyên, nhiều trang web có nghĩa là cân bằng tải và một số hack DNS, điều này sẽ nằm trong cùng một trung tâm dữ liệu? Nếu vậy, nếu một trung tâm dữ liệu bị hỏng vì bất kỳ lý do gì bạn sẽ gặp sự cố vì một phần tốt của DNS và cân bằng tải của bạn sẽ nằm trong trung tâm dữ liệu này.

Vì vậy, bạn có thể phải lập kế hoạch phân chia tình huống não. Đối với mỗi lần thiết lập có thể, cách giải quyết tình huống nhổ não là khác nhau. Ngoài ra, mỗi giải pháp mất X lượng thời gian.
Nó cũng có thể dễ dàng hơn nhiều để lập kế hoạch sử dụng 3 trung tâm dữ liệu từ đầu. Tôi không phải là chuyên gia về MySQL nhưng tôi đã nghe nói rằng trong sản xuất, việc có 3 Master dễ dàng hơn 2 nếu bạn gặp sự cố.

Một điều có thể giúp bạn là dịch vụ cân bằng tải được cung cấp bởi một số nhà cung cấp mạng như Zeus, hãy xem ở đây Có lẽ có nhiều dịch vụ cung cấp loại dịch vụ này. Tôi chắc chắn rằng nó có giá nhưng đôi khi cho phép bạn cắt giảm một số thứ khác.

Chúc may mắn!

DRBD không phải là giải pháp được đề xuất cho các trung tâm dữ liệu từ xa, vì nó yêu cầu băng thông có thể ảnh hưởng đến tốc độ của cơ sở dữ liệu và sao chép của bạn. Giải pháp được đề xuất là Master - Master Replication. Vấn đề duy nhất với điều này là các trường tăng tự động của bạn cần được đặt so le.

Nếu bạn yêu cầu một giải pháp HA thực sự cho MySQL, bạn sẽ phải sử dụng MySQL Cluster vì DRBD không thể cung cấp cho bạn tính toàn vẹn dữ liệu trong trường hợp thất bại.

Tôi đã tìm thấy các bài đăng trên blog về các tùy chọn có sẵn trong MySQL và các ưu và nhược điểm của nó. http://mysqlha.blogspot.com/2010/04/consistency-across-wan.html

Khắc phục việc thiếu cáp nối tiếp thực sự rất dễ dàng, bạn sử dụng một thứ từ thời kỳ đen tối được gọi là modem - bạn có một cái ở mỗi đầu và sau đó chạy Heartbeat qua liên kết PPP. Bạn cũng có thể sử dụng rơle khung. Cả hai phương pháp sẽ khắc phục mọi lo lắng mà bạn có với các đường dẫn dự phòng layer1 / 2.

Tuy nhiên, điều đó đang được nói - DRBD chạy trên bất kỳ liên kết nào có độ trễ lớn hơn khoảng 300 (lưu ý rằng 0,3ms) trở nên vô lý rất nhanh.

Bạn sẽ được phục vụ tốt hơn bằng cách sử dụng bản sao MySQL tiêu chuẩn và LinuxHA qua PPP & eth để thực hiện thất bại.

Ít nhất đó là những gì tôi đã làm cho khách hàng trong quá khứ.