Вот накидал картинку, прошу не пинать сильно, накидывал быстро, а то на пальцах сложно объяснять:
Серые прямоугольники - ДЦ. Произвольное количество, я нарисовал 3.
Желтые прямоугольники - физические сервера. В моем примере их по 3 на ДЦ, итого 9.
Красные прямоугольники - схематически физические каналы между серверами.
В каждом датацентре стоит несколько физических серверов, которые настроены на работу между собой и между которыми настроены физически сетки. Они объединены в единую группу в между датацентрами и настроены без балансировки. На них стоит любая ось с виртуализацией (например бесплатный Hyper-V Server Core от МС) и эта ось служит прокладкой между физическим железом и нашей рабочей структурой. Единственное, что они могут делать кроме виртуализации и создания общей сети физического уровня это первоначально балансировать нагрузку. Тоесть тупо обмениваться между собой информацией периодически, у кого сколько нагрузки по виртуальным машинам и в случае, если собственная нагрузка большая а есть свободные ДЦ то отправлять нагрузку туда. Это не сложная задача, реализуется чем угодно от готовых оснасток осей до мелких самописных прог или скриптов.
Зеленые прямоугольники - виртуальные сервера. На них стоит уже сама рабочая кластеризованая (если надо) ось и кластеризованый (если надо) базовод. У меня в примере 18 виртуальных серверов.
Синие прямоугольники - виртуальная локальная сеть. Она проложена поверх физической сети и ей нет разницы, лежит ли она в рамках одного ДЦ или раскидана между ними. На схеме все виртуальные сервера соединены в единую локальную сеть, они не знают, где они находятся физически, как сконфигурирована реальная сеть, где расположены ДЦ и остальное. Ей на это пофигу.
Так как тема у нас про базы, то на каждом виртуальном сервере стоят базоводы, на нескольких серверах мастера - на нескольких - слейвы и между собой они не балансируются средствами базовода. Но так как они все крутятся на единой платформе виртуальной оси с балансировкой нагрузки, то сама ось в каждый конкретный момент времени решает, какой мастер или слейв сервер получает нагрузку, следуя при этом определенным алгоритмам (чтоб не заменить мастер сервер слейвом или слейвы не перепутать например).
Черный прямоугольник у нас динамический DNS
Синие стрелочки - пути запроса
Розовые стрелочки - альтернативные возможные пути запроса.
Как это все работает:
1) Нам поступает запрос.
Он адресован по имени домена, тоесть обрабатывается динамическим днс и он решает, что его надо отправить во второй ДЦ. Альтернативно он может его отправить в 1 или 3 ДЦ, но вот так вот решилось, что он отправился во второй.
2) Во втором ДЦ его встретил физический сервер, держащий часть виртуалок. Он видит, что машина у него не сильно загружена и отправляет запрос к себе на виртуалку master2. Как альтернатива он может отправить ее на другую виртуалку или в другой ДЦ.
3) В виртуальой машине операционка определяет, что сервер master2 завис, а master1 и так нагружен. Но он видит, что есть свободный сервер master1 в ДЦ3 (точнее он не видит ДЦ, он видит, что есть свободныйв данный момент мастер-сервер) и отправляет запрос в него.
4) Сервер обрабатывает запрос, отдает его на физический сервер в ДЦ3 и этот физический сервер отдает запросчику готовый ответ.
Схема примерная. Если кто хочет мне сказать, что там еще что то должно быть, пусть сам рисует и сам строчит большие посты с этим все, я с удовольствием их почитаю и покритикую
Схема примерная и всего один из вариантов решения.
Что будет, если что-то сдохнет:
Допустим, у нас случился форс-мажор, и в ДЦ3 сдох сервер 2.
Нам будет это совершенно параллельно, потому что на сервере останется свободный master1-сервер и его слейвы slave21 (полное зеркало сдохшего на втором серевере slave11 ) и slave12 со своей копией slave22. Сама ось в реалтайме подменит вылетевшие сервера оставшимися на физических у себя или на любом другом сервере в любом другом датацентре.
Если у нас сдохнет весь датацентр, то все повториться точно так же, оставшиеся виртуальные сервера сбалансируют нагрузку а динамический ДНС просто не будет в сдохший ДЦ посылать запросы до тех пор, пока он не отживет.
Из-за того, что виртуально у нас все собрано в единую сеть, запросы могут обрабатываться на любой свободной конфигурации серверов, тоесть например поступил запрос на master2 в ДЦ1, а в качестве слейвов для его обработки могут выступить свободные в данный момент времени slave11 в ДЦ3 и slave22 в ДЦ2. Сама синхронизация виртуальных серверов вполне может проходить на уровне виртуальных машин и существующих технологий синхронизации снимков машин, тоесть виртуальная сеть даже не будет знать, что ее элементы синхронизируются.
Кроме того, мы можем в любой форме и в любом порядке отключать или подключать физические сервера и датацентры, главное, чтоб у нас в любой момент времени работало 2 из 9 физических серверов и всеравно где - нагрузка будет сбалансирована. По производительности она будет равна 9 отдельным серверам. При этом скорее всего может проиграть им если их сгруппировать по 3 для создания 3-х мастер-слейв систем (проиграет в 2 раза) либо если на каждом собрать по отдельному базоводу (проиграет по количеству обработаных запросов в 1.5 раза). Но в сумме она будет делать то же количество работы, но с гораздо больше гибкостью и решенными вопросами по распераллеливанию всей системы.
Это был только один из примеров. Если наш базовод поддерживает и репликацию базы на несколько мастер-слейв серверов и балансировку нагрузки между несколькими мастер-серверами, то все примочки типа виртуальной сети и балансировки силами операционки нам не нужны. Но этот вариант уже проще, если вы поняли мой пример, этот пример будет понять уже легче и проще.
Всю подробную информацию можно легко нагуглить. Нет сложностей с манулами по виртуализации и созданию между несколькими физическими серверами пусть и в разных ДЦ единой виртуальной сети виртуальных же машин. Нет никаких сложностей с мануалами по кластеризации конкретных осей и балансировки нагрузки между нодами, ее составляющими. Нет никаких сложностей с манулами по кластеризации конкретных базоводов. просто берите то, что надо под конкретную задачу и читайте.
п.с. Сам я в рамках грубо говоря одного ДЦ распараллеливал MySQL без проблем. Мне не нужно было несколько датацентров, по этому задача не стояла такая. Взял на одной машине поднял виртуалку, поставил туда мастер и 2 слейв мускула, сделал отдельно им фронтэнд, расписал кто как физические ресурсы кушает и получил в локальной задаче примерно в 3.5 раза прирост производительности на том же железе.
