Что нового в windows server 2016 failover clustering / блог компании microsoft / хабр

Шардирование

Шардирование в ClickHouse позволяет записывать и хранить порции данных в кластере распределенно и обрабатывать (читать) данные параллельно на всех узлах кластера, увеличивая throughput и уменьшая latency. Например, в запросах с GROUP BY ClickHouse выполнит агрегирование на удаленных узлах и передаст узлу-инициатору запроса промежуточные состояния агрегатных функций, где они будут доагрегированы.

Для шардирования используется специальный движок , который не хранит данные, а делегирует SELECT-запросы на шардированные таблицы (таблицы, содержащие порции данных) с последующей обработкой полученных данных. Запись данных в шарды может выполняться в двух режимах: 1) через Distributed-таблицу и необязательный ключ шардирования или 2) непосредственно в шардированные таблицы, из которых далее данные будут читаться через Distributed-таблицу. Рассмотрим эти режимы более подробно.

В первом режиме данные записываются в Distributed-таблицу по ключу шардирования. В простейшем случае ключом шардирования может быть случайное число, т. е. результат вызова функции . Однако в качестве ключа шардирования рекомендуется брать значение хеш-функции от поля в таблице, которое позволит, с одной стороны, локализовать небольшие наборы данных на одном шарде, а с другой — обеспечит достаточно ровное распределение таких наборов по разным шардам в кластере. Например, идентификатор сессии (sess_id) пользователя позволит локализовать показы страниц одному пользователю на одном шарде, при этом сессии разных пользователей будут распределены равномерно по всем шардам в кластере (при условии, что значения поля sess_id будут иметь хорошее распределение). Ключ шардирования может быть также нечисловым или составным. В этом случае можно использовать встроенную хеширующую функцию . В рассматриваемом режиме данные, записываемые на один из узлов кластера, по ключу шардирования будут перенаправляться на нужные шарды автоматически, увеличивая, однако, при этом трафик.

Более сложный способ заключается в том, чтобы вне ClickHouse вычислять нужный шард и выполнять запись напрямую в шардированную таблицу. Сложность здесь обусловлена тем, что нужно знать набор доступных узлов-шардов. Однако в этом случае запись становится более эффективной, и механизм шардирования (определения нужного шарда) может быть более гибким.

Кластеризация веб- и FTP-служб

Приведенные ниже сведения описывают установку IIS на кластер серверов. Более подробные сведения о кластерах серверов, включая описание использования администратора кластеров, см. в документации Windows 2000 Advanced Server.

Каждый кластеризованный веб- или FTP- узел IIS включает:

Ресурс кластера IIS.
IP-адрес ресурса кластера, от которого зависит ресурс веб- или FTP-узла IIS.

Чтобы установить IIS на кластер серверов

В Cluster Administrator выберите группу, в которую будет добавляться новый ресурс. Группа — это единица замены при сбое в кластеризованной среде. Для первого ресурса IIS обычно это «Cluster Group». Для любых других ресурсов IIS обычно это новая группа. Выбор новой группы приведет к тому, что ресурсы в новой группе будут заменяться при сбое независимо.
В меню File выберите команды New и Resource. В диалоговом окне введите имя и описание нового ресурса, затем выберите тип ресурса IIS Server Instance из раскрывающегося списка. Нажмите кнопку Next.
Из списка выберите узлы кластера, на которых ресурс должен быть доступен. Чтобы обеспечить замену при сбое, должны быть выбраны оба узла. Эта установка используется по умолчанию. Нажмите кнопку Next.
В области переходов выберите зависимость для нового ресурса. Ресурсы кластера IIS требуют по крайней мере одну зависимость адреса IP кластера, например Cluster IP Address. Нажмите кнопку Add для выбора зависимостей. Нажмите кнопку Next.

Примечания

Зависимость IP-адреса нужна для успешного выполнения замены при сбое. Экземпляр сервера IIS должен иметь зависимость IP-адреса, чтобы при переключении IIS при сбое на второй узел кластера IP-адрес, нужный для связывания с экземпляром сервера IIS, также переключался на второй узел.
Если содержимое хранится на кластеризованном диске в кластере, проверьте, что экземпляр сервера IIS сконфигурирован зависящим от кластеризованного диска. Если этого не сделано, кластеризованный IIS сервер может подключиться к узлу, который не имеет доступа к кластеризованному диску, и IIS не сможет получить доступ к содержимому после замены при сбое.
Проверьте, что имена и пароли всех анонимных пользователей, используемые в конфигурациях веб-узла, применимы на всех узлах кластера. Все пути виртуальных каталогов должны или указывать на общий диск (то есть, UNC или жесткий диск кластера), или на одинаковые локальные диски (то есть, одинаковые буквенные обозначения диска и структуры каталогов для всех узлов кластера).

Выберите или FTP, или WWW. Выберите сервер из раскрывающегося списка. Нажмите кнопку OK.

Если веб- или FTP-узлы привязаны к IP-адресу, используйте ресурс Cluster IP Address и сделайте ресурс кластера IIS зависимым от ресурса Cluster IP Address.

Важно! Для установки свойств веб- или FTP-узла используйте оснастку IIS. С помощью оснастки IIS можно также запустить и остановить веб- и FTP-узлы на некластеризованном компьютере, но для запуска и остановки веб- и FTP-узлов на кластеризованном компьютере необходимо использовать программу Cluster Administrator

Репликация параметров настройки

Чтобы реплицировать параметры настройки с одного веб- или FTP-сервера на другой

На исходном (основном) сервере в режиме командной строки перейдите в папку со служебной программой — %SystemRoot%\system32\inetsrv.
Реплицируйте параметры настройки, введя: iissync цель, где цель — это имя компьютера, на который необходимо реплицировать параметры настройки.
Чтобы реплицировать параметры настройки с основного компьютеры на несколько других компьютеров одновременно, перечислите их имена, отделяя запятыми, после команды iissync. Например, iissync clusternode_2 clusternode_3 … и так далее.

Примечания

Данную программу следует запускать по необходимости для сохранения надежной репликации параметров настройки на обоих серверах-узлах. Данная программа автоматически не синхронизирует параметры настройки и не распознает внесенные изменения конфигурации.
Если подчиненный сервер уже содержит IP-адрес, привязанный к имени хост-компьютера и порту, этот адрес IP не изменяется при копировании конфигурации.
Перед запуском программы Iissync.exe кластеры уже должны быть созданы. Если используется неправильное имя компьютера, возвращается сообщение об ошибке, репликация не производится.

Инструмент миграции DDL-запросов

Для миграции DDL-запросов для реляционных СУБД в нашей компании используется MyBatis Migrations.

Об инструментах миграции на Хабре уже писали:

Версионная миграция структуры базы данных: основные подходы
Простые миграции с PHPixie Migrate
Управление скриптами миграции или MyBatis Scheme Migration Extended

Для работы с ClickHouse-кластером нам требовался аналогичный инструмент.

На момент написания статьи ClickHouse имеет ряд особенностей (ограничений) связанных с DDL-запросами. :

Команда разработчиков ClickHouse уже анонсировала работу в этом направлении, но в настоящее время приходится решать эту задачу внешним инструментарием. Мы создали простой прототип инструмента phpMigrationsClickhouse для миграции DDL-запросов в ClickHouse-кластер. И в наших планах — абстрагировать phpMigrationsClickhouse от языка PHP.

Опишем алгоритм, использующийся в настоящий момент в phpMigrationsClickhouse, который может быть реализован на любом другом языке программирования.

На текущий момент инструкция по миграции в phpMigrationsClickhouse состоит из:

SQL-запросов, которые нужно накатить и откатить в случае ошибки;
имени кластера, в котором нужно выполнить SQL-запросы.

Создадим PHP-файл, содержащий следующий код:

Добавим SQL-запросы, которые нужно накатить:

Добавим SQL-запросы для выполнения отката в случае ошибки:

Существует 2 стратегии накатывания миграций:

отправка каждого отдельного SQL-запроса на один сервер с переходом к следующему SQL-запросу;
отправка всех SQL-запросов на один сервер с переходом к следующему серверу.

При возникновении ошибки возможны следующие варианты:

выполнение downgrade-запроса на все узлы, на которых уже были произведены upgrade-запросы;
ожидание перед отправкой upgrade-запросов на другие сервера;
выполнение downgrade-запроса на всех серверах в случае возникновения ошибки.

Отдельное место занимают ошибки, когда не известно состояние кластера:

ошибка timeout соединения;
ошибка связи с сервером.

Принцип работы PHP-кода при выполнении миграции следующий:

В случае ошибки выполняется отправка на все узлы кластера downgrade-запроса:

Мы продолжим цикл материалов, посвященных нашему опыту работы с ClickHouse.

Примеры конфигурации ClickHouse-кластера

В качестве примеров будем рассматривать различные конфигурации для четырех узлов: . Настройки содержатся в конфигурационном файле /etc/clickhouse-server/config.xml.

Один шард и четыре реплики

Пример схемы создания таблицы:

Пример SQL-запроса создания таблицы для указанной конфигурации:

Преимущество данной конфигурации:

Недостатки:

Для большинства задач будет храниться избыточное количество копий данных.
Поскольку в данной конфигурации только 1 шард, SELECT-запрос не может выполняться параллельно на разных узлах.
Требуются дополнительные ресурсы на многократное реплицирование данных между всеми узлами.

Пример SQL-запроса создания таблицы для указанной конфигурации:

Преимущество данной конфигурации:

Недостаток:

Два шарда по две реплики

Пример SQL-запроса создания таблицы для указанной конфигурации:

Данная конфигурация воплощает лучшие качества из первого и второго примеров:

Поскольку в данной конфигурации 2 шарда, SELECT-запрос может выполняться параллельно на каждом из шардов в кластере.
Относительно надежный способ хранения данных (потеря одного узла кластера не приводит к потере порции данных).

Репликация

ClickHouse поддерживает данных, обеспечивая целостность данных на репликах. Для репликации данных используются специальные движки MergeTree-семейства:

ReplicatedMergeTree
ReplicatedCollapsingMergeTree
ReplicatedAggregatingMergeTree
ReplicatedSummingMergeTree

Репликация часто применяется вместе с шардированием. Например, кластер из 6 узлов может содержать 3 шарда по 2 реплики. Следует отметить, что репликация не зависит от механизмов шардирования и работает на уровне отдельных таблиц.

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

Список источников