Архітектура високодоступних MySQL з автоматичним відмовою у фізично різних місцях

Я досліджував рішення високої доступності (HA) для MySQL між центрами обробки даних.

Для серверів, розташованих в одному фізичному середовищі, я віддав перевагу подвійному майстру з серцебиттям (плаваючий VIP), використовуючи активний пасивний підхід. Серцебиття перебуває як через послідовний зв'язок, так і через мережеве з'єднання.

Зрештою, моя мета - підтримувати такий самий рівень доступності, але між центрами обробки даних. Я хочу динамічно переходити між обома центрами обробки даних без ручного втручання і все ж підтримувати цілісність даних.

Зверху буде BGP. Веб-кластери в обох місцях, які мали б потенціал для маршрутизації до баз даних між обома сторонами. Якщо підключення до Інтернету знизилось на сайті 1, клієнти прокладуть маршрут через сайт 2, до веб-кластеру, а потім до бази даних на сайті 1, якщо зв’язок між обома сайтами все ще працює.

При такому сценарії через відсутність фізичного зв’язку (серійного) існує більша ймовірність розщеплення мозку. Якщо WAN знизився між обома сайтами, VIP виявився б на обох сайтах, де різноманітні неприємні сценарії могли ввести десинхронізацію.

Ще одна потенційна проблема, яку я бачу, - це складність масштабування цієї інфраструктури до третього центру обробки даних у майбутньому.

Мережевий шар - це не фокус. На цьому етапі архітектура гнучка. Знову ж таки, мою увагу приділено вирішенню для збереження цілісності даних, а також автоматичного відмови від баз даних MySQL. Я б, швидше за все, спроектував решту навколо цього.

Чи можете ви порекомендувати перевірене рішення для MySQL HA між двома фізично різноманітними сайтами?

Дякую, що знайшли час, щоб прочитати це. Я з нетерпінням чекаю ваших рекомендацій.

Ви зіткнетеся з проблемою теореми "CAP". Ви не можете одночасно мати послідовність, доступність та толерантність до розділів.

DRBD / MySQL HA покладається на синхронну реплікацію на рівні блочного пристрою. Це добре, коли обидва вузли доступні, або якщо хтось зазнав тимчасової несправності, перезавантажився тощо, то повертається назад. Проблеми починаються, коли ви отримуєте мережевий розділ.

Мережеві розділи надзвичайно вірогідні, коли ви працюєте в двох центрах даних. По суті, жодна із сторін не може відрізнити розділ від іншого вузла, який виходить з ладу. Вторинний вузол не знає, чи повинен він переймати (первинний не вдався) чи ні (посилання відсутнє).

Поки ваші машини знаходяться в одному місці, ви можете додати вторинний канал зв'язку (як правило, послідовний кабель або кроссовер Ethernet), щоб подолати цю проблему - таким чином, вторинний знає, коли основний ВЗАЄМО вниз, і це не мережевий розділ .

Наступна проблема - продуктивність. У той час як DRBD може забезпечити пристойну ** продуктивність, коли ваші машини мають низький запізнювальний зв’язок (наприклад, гігабітна Ethernet - але деякі користуються спеціалізованими високошвидкісними мережами), чим більше затримка в мережі, тим більше часу потрібно для здійснення транзакції *** . Це тому, що йому потрібно дочекатися, коли вторинний сервер (коли він є в Інтернеті) підтвердить усі записи, перш ніж сказати "ОК" додатку, щоб забезпечити довговічність записів.

Якщо ви робите це в різних центрах обробки даних, у вас зазвичай затримка ще кілька мілісекунд, навіть якщо вони знаходяться поруч.

** Ще набагато повільніше, ніж пристойний локальний IO-контролер

*** Ви не можете використовувати MyISAM для системи DRBD з високою доступністю, оскільки вона не відновлюється належним чином / автоматично після нечистого відключення, необхідного під час відмови.

А як щодо використання VLAN для з'єднання всіх серверів у двох (або більше) центрах обробки даних. Потім ви можете використовувати CARP для автоматичного виходу з ладу. Використовуйте реплікацію бази даних, щоб підтримувати синхронізацію всього.

Якщо у вас є центри обробки даних, ви можете переконатися, що кожен центр обробки даних має декілька посилань WAN.

Вашим першим етапом має бути оновлення вашого поточного рішення HA до такого, яке використовує OpenAIS як рівень членства в кластері: це дасть вам велику гнучкість, а зважаючи на низькі затримки зв’язків між сайтами, ви зможете досягти поперек. PaceMaker та RHEL Clustering це підтримують.

Для автоматичного відмовлення в центрі обробки даних вам дійсно потрібен третій сайт, який виконує функції автоматичного вимикача, інакше ваші сайти не зможуть розрізнити між проблемами маршрутизації між сайтами та відмовою на віддаленому сайті. Майкрософт має напрочуд гарні веб-касти, які охоплюють цю область:

Кластеризація багатьох сайтів Windows Server 2008

Очевидно, що точна технологія не відображається на домені Linux, але концепції однакові.

Вибачте, це ще одна мережа вбік, але думка про дорогу ...

Для згаданого вами сценарію розділеного мозку ви могли мати надлишкові зв’язки між двома сайтами, а також зменшити шанс цього статися.

Зауважте, що ви, ймовірно, не можете використовувати BGP, оскільки найменший блок маршрутизації - 4k, a / 22, удача отримати його. Можливо, потрібне рішення на базі DNS.

Дати правильну відповідь може бути важко залежно від кількості ваших даних, кількості серверів, на які ви хочете це вписати і т. Д. При цьому, моя відповідь може бути не однією, або хоча б такою, яку ви шукаєте.

Немає перевіреного рішення для декількох сайтів з MySQL. Але є рішення, яке працює. Як зазначали деякі, так, DRDB працює нормально, але має обмеження або можливу проблему залежно від налаштувань.

Вам коли-небудь знадобиться третій сайт (інший центр обробки даних)? Якщо так, то скільки часу та грошей вам доведеться це робити?

Враховуючи кожен раз, коли ви додаєте головний / підлеглий / dns сервер, резервне копіювання, ... ви додаєте собі сервер для управління, яка ваша здатність управління щодо кількості серверів? Якщо ви можете визначити це число, можливо, вам доведеться відкинути деякі можливі рішення та працювати над тими, які будуть відповідати вашим номерам, щоб управління не стало вузьким місцем.

Зважаючи на те, що центри обробки даних не спускаються часто, кілька сайтів означають балансування навантаження та деяке злому DNS, чи буде це в одному центрі обробки даних? Якщо так, якщо один центр обробки даних знищиться з будь-якої причини, ви зіткнетеся з проблемою, оскільки значна частина вашого DNS і балансування навантаження буде знаходитися в цьому центрі обробки даних.

Тож вам, можливо, доведеться планувати цю розділену ситуацію з мозком. Для всіх можливих налаштувань спосіб вирішити ситуацію з косою мозку різний. Крім того, кожен розчин займає X кількість часу.
Також може бути набагато простіше запланувати використання 3 центрів обробки даних з самого початку. Я не фахівець з MySQL, але я чув, що у виробництві було легше мати 3 майстри, ніж 2, якщо ти коли-небудь стикався з проблемою.

Одна річ , яка може допомогти вам, балансування навантаження послуг , пропонованих деякими мережі постачальника , як Зевс, дивіться тут Існує, ймовірно , багато інших пропонують цей вид послуг. Я впевнений, що це ціна, але іноді дозволяє вам скоротити деякі інші речі.

Удачі!

DRBD не є рекомендованим рішенням для віддалених центрів обробки даних, оскільки він вимагає пропускної здатності, яка може впливати на швидкість роботи вашої бази даних та реплікацію. Рекомендоване рішення - Master - Master Replication. Єдине питання з цим полягає в тому, що ви автоматично збільшуєте поля автоматичного збільшення.

Якщо вам потрібне справді рішення HA для MySQL, вам доведеться працювати з кластером MySQL, оскільки DRBD не може надати вам цілісність даних у разі відмов.

Я знайшов повідомлення в блозі про варіанти, доступні в MySQL та його плюси та мінуси. http://mysqlha.blogspot.com/2010/04/consistency-across-wan.html

Подолати відсутність послідовного кабелю насправді дуже просто, ви використовуєте річ із темних віків, яку називають модемом - у вас є її на кожному кінці, а потім запустіть Heartbeat через PPP-посилання. Також можна використовувати рамне реле. Обидва способи виправлять будь-які турботи, що виникають у вас із зайвими шляхами слой1 / 2.

Однак, як кажуть - затримка DRBD, що працює над будь-якою ланкою з набагато більше ніж 300 мкс (зауважте, що 0,3 мс), затримка стає дуже смішною дуже швидко.

Вам краще послужити, використовуючи стандартну реплікацію MySQL та LinuxHA через PPP & eth, щоб робити помилки.

Принаймні, це те, що я робив для клієнтів у минулому.