Нас попросили предоставить систему, в которой центральный сервер базы данных продолжает свою работу, даже при применении обновлений безопасности к операционной системе сервера или к программному обеспечению сервера базы данных. Насколько я понимаю, это включает обновления безопасности, требующие перезагрузки сервера (ов).
Технология кластеров кажется очевидной, но если сервер действительно может перезагружаться во время использования кластера, у меня есть пара вопросов:
Разница между надежной системой и системой с нулевое время простоя это разница между выводом алюминиевого шара на низкую околоземную орбиту и высадкой человека на Луну и безопасным возвращением его обратно.
Я бы посмотрел на старые способы сделать это, и, на мой взгляд, это те, на которые вам следует обратить внимание, если вам нужно, чтобы это сработало с первого раза, а не унесло бюджет.
Старыми резервными являются кластеры OpenVMS и Tandem (теперь HP) NonStop. Оба они предназначены для нескольких компьютеров, на которых работает одна и та же БД и один и тот же код. Оба предназначены для обеспечения 100% бесперебойной работы даже при обновлении ОС и программного обеспечения и исправлениях. Оба имеют проверенный многолетний опыт правильной работы.
Теперь - есть современные вещи, которые обеспечат это на бумаге. На практике вы столкнетесь с такими проблемами, как "упс, мы допустили ошибку на нашем сервере лицензий, и теперь ваши виртуальные машины не загружаются«Я уверен, что через десять лет эти технологии будут проверены и доказаны, что их надежность, но до тех пор, если вам нужно, чтобы они работали, будьте очень консервативны в том, какие истории вы верите.
И, наконец, самое главное для создания такой надежной системы - это хорошо спроектировать, построить и позаботься об этом хорошо потому что на практике наименее надежная вещь в уравнении - это человек, стоящий за клавиатурой.
Кластер MySQL http://www.mysql.com/products/database/cluster/
Никакого прерывания во время планового обслуживания, включая перезапуск ОС? Oracle RAC. Это единственный реальный вариант, о котором я могу думать, и, безусловно, единственная база данных параллельного кластера, которой я бы доверял. Даже RAC иногда должен отключаться для исправлений базы данных, но большинство из них можно применить во время работы.
Если вы можете справиться с простоями не менее 10-15 секунд, существует ряд других вариантов, включая кластеризацию на уровне приложений (кластер Veritas, кластер Microsoft, Oracle clusterware) или репликацию на уровне базы данных. Сама по себе виртуальная инфраструктура не очень поможет. ОС по-прежнему должна выйти из строя.
Также можно комбинировать реплицированные базы данных с многосетевым клиентом для непрерывного производства, хотя я все равно не могу вспомнить имена таких клиентов на данный момент.
Я мог бы добавить, что вы, вероятно, захотите использовать какой-нибудь * NIX, чтобы свести их перезагрузку к минимуму. Насколько я помню, за последние пару лет было только одно обновление, которое стоило перезагрузить на RHEL и OEL.
Oracle RAC - это параллельный кластер. База данных хранится в общем хранилище и доступна всем узлам одновременно. Если все сделано правильно, в большинстве случаев это должно улучшить общую производительность и практически не повлиять на время ответа на запрос. Однако это сложная технология, и сделать ее правильно - далеко не тривиально.
Есть несколько других параллельных технологий, которые обещают пять девяток (99,999% времени безотказной работы, равное 5 минутам простоя в год), но они либо слишком старые (VAX), либо слишком новые (NDB).
Есть несколько способов сделать это. Кластеры на уровне ОС могут работать с кратковременным отключением при переходе с одного узла на другой. Вы не указали платформу своей ОС. Большинство платформ? NIX имеют надежное решение для кластеризации.
Что касается платформы БД, у Oracle есть свой общий подход ко всему с RAC, где вы можете отключить один узел, и все будет перемещено на другие узлы в кластере. Это позволяет вам выполнять обслуживание на узле, в то время как другие узлы продолжают работать и обслуживать клиентов. Все они используют один и тот же набор дисков. Влияние на производительность зависит от размера оборудования, большинство устанавливает размер своего оборудования на N + 1, чтобы гарантировать, что производительность не будет снижена при выполнении этого типа деятельности.
В последней версии Informix есть нечто подобное. Предполагается, что DB2 скоро получит это.
Я считаю, что единственный способ сделать это - использовать кластеризация. Вам понадобится несколько серверов БД, которые объединены в кластер. Тогда один сервер может автоматически заменить другой, вышедший из строя. Это называется «отказоустойчивым» (или кластером высокой доступности).
Чтобы ответить на ваши вопросы:
Какие продукты для баз данных могут это сделать?
Все это рекламирует «поддержку кластеризации». Я знаю, по крайней мере, MySQL и Oracle, но многие другие СУБД, вероятно, также поддерживают это.
Как это работает? Хранит ли он данные базы данных на всех серверах одновременно, или задачи одного сервера передаются другому во время его перезагрузки?
Обе. Серверы регулярно синхронизируют свои данные, поэтому они хранятся на всех серверах. Что касается того, какой сервер фактически отвечает на запросы, есть два варианта: в кластере с балансировкой нагрузки все серверы разделяют нагрузку (так что вы получаете лучшую производительность), в кластере высокой доступности обычно выполняет работу один компьютер, а Запасной берет на себя, если он терпит неудачу (переключение).
Как это влияет на производительность, особенно на задержку запросов?
Извините, у меня нет опыта в этом. Обычно накладные расходы должны быть минимальными, но отработка отказа может занять некоторое время и вызвать тайм-ауты.
Я не слышал о некоторых других упомянутых решениях, поэтому я не могу сравнивать их, но поскольку я не вижу здесь того, с которым я знаком, я тоже упомяну его.
То есть MySQL поверх файловой системы DRBD. С сердцебиением linux как описано здесь
Мы использовали его пару лет без простоев. Наша единственная проблема заключалась в том, что мы запускали наш кластер на виртуальных машинах, и он действительно должен быть на физических компьютерах с несколькими путями между ними (например, Ethernet, последовательный кабель и т. Д.)
Это работает так: DRBD похож на рейд на несколько машин, где он поддерживает непрерывную синхронизацию базовой файловой системы между двумя или более хостами, в то время как Heartbeat позволяет файловой системе / базе данных работать только на одном сервере за раз.
Аварийное переключение при выходе из строя происходит очень быстро - и его можно настроить еще быстрее, если соединения между машинами являются избыточными и очень надежными. (это была наша проблема с использованием виртуальных машин). Кроме того, за счет отработки отказа до запланированной перезагрузки даже это можно свести к минимуму.
Это можно сделать двумя способами: VMware FT (хотя и ограничивается одним процессором), а другой - технология кластеризации.
VMware FT не имеет проблем с задержкой, НО вы ограничены одним процессором, а решение для кластеризации часто имеет время переключения при отказе около 15 секунд, так как сеанс TCP переключается на новый сервер, а время ожидания старых сеансов TCP, включая обновление ARP в локальной сети.
MS SQL может кластеризоваться на нескольких серверах - требуется общий диск с другого сервера. MySQL может реплицировать данные с отношениями главный / подчиненный между несколькими узлами. Oracle RAC создаст кластер с несколькими узлами. Сервер Sybase rep может реплицировать данные на несколько серверов.
И да, вы можете просто запустить все в VMWare, а затем использовать FT или Motion для перемещения ОС между узлами, работающими с данными, хранящимися в SAN.
Я бы сказал, что одним из способов сделать это будет репликация мастер-мастер с использованием MySQL. Убедитесь, что ваше приложение является многосетевым, чтобы использовать второй мастер, если первый недоступен, тогда вы можете отключить один мастер, в то время как другой остается активным как для чтения, так и для записи. Когда ваш второй сервер вернется, просто поверните его в другую сторону. Вставка в таблицу происходит со значениями PK, разнесенными на 2, а не на 1, но это нормально, это просто ключ.
Я ищу решения, которые могут поддерживать транзакцию открытой, даже когда компьютер, на котором установлено программное обеспечение сервера базы данных (виртуальный или физический), перезагружается.
Я думаю, вам нужно будет взглянуть на HA-JDBC, чтобы удовлетворить это требование: http://ha-jdbc.sourceforge.net/
«Высокая доступность / отказоустойчивость - кластер базы данных HA-JDBC может потерять узел без сбоя / повреждения открытых транзакций».
Ура
MSSQL с кластеризацией Windows будет обрабатывать 0 окон обслуживания простоев ПРИ УСЛОВИИ вы отказываетесь от узла, над которым собираетесь работать, ДО того, как вы начнете работу. Кроме того, вам необходимо настроить NLB на хостах, чтобы убедиться, что все соединения обрабатываются через общий IP-адрес (в противном случае может быть до 2 или более секунд простоя, пока серверы повторяют попытку DNS и т. Д.). Чтобы кластеризация работала, вам понадобится общий массив хранения, такой как iSCSI, и 2 или более физических хоста (гипервизоры тоже нуждаются в обновлении).
Вот довольно хорошая информация о том, как будет выглядеть эта среда, но в основном, если у вас не может быть простоя, вам понадобится как минимум один администратор базы данных MS SQL в штате и по вызову, чтобы гарантировать, что все отработки отказа происходят правильно, и вы можете ' не дешеветь на НИЧЕГО. Позвоните в Microsoft и ознакомьтесь с их книгой по этому поводу, а еще лучше разместите свое приложение в облаке в Azure или у поставщика выделенного сервера, который специализируется на высокой доступности.