Комментарии 5
А почему все используют бгп, но не используют bgp multipath, а делают костыли с днс и несколькими айпишниками?
0
хм, может быть я чего-то недопонимаю, но здесь с помощью BGP и анонса одного и того же ip адреса из разных DC достигается отказоустойчивость балансировщика. Как Вы с помощью bgp multipath сделаете тоже самое?
С помощью DNS запросы отправляются на несколько балансировщиков одновременно. Как Вы с помощью bgp multipath сделаете тоже самое?
Если не затруднит пример конфигурации.
С помощью DNS запросы отправляются на несколько балансировщиков одновременно. Как Вы с помощью bgp multipath сделаете тоже самое?
Если не затруднит пример конфигурации.
0
Здравствуйте, Артем!
Вы пишете:
А каким образом создается «зеркальная копия»? Мультимастер репликация в mariadb? Но в таком подходе некоторые данные могут пропасть при потере всего одного диска…
Может быть, какая-то другая технология используется?
Не очень понятно, что значит «остальные поддерживаются плохо»? Ну и про «слабое место» интересно — Вы считаете, что успешно скомпенсировали эту «слабость» архитектурой и лучшего решения нет? Это не очень понятно из текста статьи.
Вы пишете:
В случае отказа одного из дата-центров мы имеем зеркальную копию наших сервисов во втором дата-центре, которые принимают всю нагрузку на себя.
А каким образом создается «зеркальная копия»? Мультимастер репликация в mariadb? Но в таком подходе некоторые данные могут пропасть при потере всего одного диска…
Может быть, какая-то другая технология используется?
Передача происходит с помощью брокера сообщений, как правило это RabbitMQ, остальные поддерживаются плохо.
…
Слабым местом во всей схеме являются RabbitMQ и MariaDB.
Не очень понятно, что значит «остальные поддерживаются плохо»? Ну и про «слабое место» интересно — Вы считаете, что успешно скомпенсировали эту «слабость» архитектурой и лучшего решения нет? Это не очень понятно из текста статьи.
+2
Не очень понятно, что значит «остальные поддерживаются плохо»
Cервисы Openstack по дефолту предполагают использование с RabbitMQ. docs.openstack.org/security-guide/messaging.html
Фраза не совсем верна, правильнее будет сказать, что опыта эксплуатации других message queue совместно с Openstack у нас крайне мало. Хотя возможность замены RabbitMQ мы не исключаем.
Ну и про «слабое место» интересно — Вы считаете, что успешно скомпенсировали эту «слабость» архитектурой и лучшего решения нет? Это не очень понятно из текста статьи.
Как я и пишу, отказоустойчивость и масштабирование MariaDB и RabbitMQ заслуживает отдельной статьи. К сожалению, сейчас еще рано выносить на публику решение которое мы нашли для себя. Возможно в дальнейшем мы его опубликуем. Вкратце могу сказать, что в основе лежит разделение баз и брокеров по сервисам.
+2
В который раз убеждаюсь, что HAProxy — очень замечательный инструмент. Жалко, что создатели подобного ПО в качестве профита получают только "плюсы в карму".
+2
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как реализуется отказоустойчивая веб-архитектура в платформе Mail.ru Cloud Solutions