Я хотел бы иметь высокодоступную систему MySQL с автоматическим переключением при отказе, работающую на инстансах Amazon EC2.
Стандартный подход к решению этой проблемы - Heartbeat + DRBD, но я нашел много сообщений, в которых предлагалось, что DRBD не работает на EC2, хотя никто не говорит, почему именно. Очевидно, что в виртуализированной среде не может быть и речи о последовательном пульсе или отдельной сети. Также было бы хорошо, если бы разные серверы находились в разных зонах доступности, но мы попадаем в намного более сложная проблема там.
Что думают люди о решениях с высоким временем безотказной работы в «облаке»?
Примечание: Этот вопрос был задан до того, как было объявлено о RDS с несколькими зонами доступности, что является хорошим автоматическим ответом для сегодняшних современных ИТ-специалистов. :)
Я думаю, вам действительно нужна установка многозонной RDS, которая недавно была добавлена в AWS.
Подробнее здесь: http://aws.typepad.com/aws/2010/05/amazon-rds-multi-az-deployment.html
Если вы не спрашиваете об AWS, я бы предложил установку, включающую DRBD. Это обеспечит постоянную синхронизацию обоих серверов. Но я почти на 100% уверен, что это пока невозможно на AWS.
В общем, я бы был осторожен со снимками и всем остальным - это не серебряная пуля! На AWS это займет много времени. Само хранилище экземпляров: а) совсем не быстрое и б) непостоянное! Даже с EBS это не очень быстро, и вам все равно нужно останавливать ввод-вывод для получения согласованного снимка.
Дешевый простой вариант - самостоятельно установить mysql в разные центры обработки данных в EC2 и настроить репликацию master / master между ними. Направьте свои интерфейсные веб-серверы в каждом центре обработки данных на эти реплицированные серверы mysql. Настройте автоматическое переключение DNS между интерфейсными веб-серверами в каждом месте, если проверка работоспособности содержимого на вашем основном сайте завершится неудачно - он автоматически перенаправит клиентский трафик на реплицированный сайт в другом центре обработки данных - вы исправите основной сайт и проверки работоспособности начните проходить снова - тогда трафик автоматически вернется на основной сайт. Я делаю это все время - даже между разными поставщиками, например, EC2 и Linode. Он отлично работает, и переключение клиентского трафика происходит менее чем за 1 минуту. Вы можете получить автоматическое переключение DNS при отказе от dnshat.com по дешевке.
Самостоятельным вариантом будет установка MySQL на том EBS, использование эластичного IP-адреса или динамического DNS для переключения сервера, на который вы указываете, в случае сбоя.
Вам понадобится внешний сервер, отслеживающий пульс, который затем отключит том EBS, перемонтирует его на резервный сервер, а затем либо переназначит IP-адрес, либо изменит DNS. Если вы беспокоитесь о самой файловой системе, вам придется сделать снимок lvm или что-то еще, чтобы получить копии ваших данных, а затем вы можете сделать их резервную копию на том S3 или EBS.
Мне нравится иметь данные на самом томе EBS, потому что вы можете получить его моментальные снимки EBS для резервного копирования, не вмешиваясь в работу с lvm, если вам это кажется пугающим.
Также следует отметить, что у Amazon есть Пакет Enterprise MySQL который я не использовал, но, вероятно, это лучший вариант. Их цены обычно довольно разумны для контрактов на поддержку.
Я бы по умолчанию использовал активную / пассивную репликацию с двумя главными серверами с использованием плавающего VIP. (Heartbeat, OpenAIS, MMRM или Pacemaker)
Я не могу придумать причину, по которой это плохая идея. Ты можешь?