Механизм аварийного переключения Managed
Dynatrace Managed позволяет выполнять развертывание с высокой доступностью в одном или нескольких центрах обработки данных, которые состоят из нескольких одинаково важных узлов, на которых выполняются одни и те же службы.
Для достижения наилучшего отказоустойчивого развертывания мы рекомендуем следующее:
Резервирование
Запланируйте развертывание минимум трех узлов на кластер. В таких кластерах все узлы автоматически реплицируют данные между узлами, поэтому обычно есть две реплики в дополнение к первичному осколку.
Избегайте проблем с синхронизацией разделенного мозга
Хотя кластеры с двумя узлами технически возможны, мы не рекомендуем этого делать. Наши системы хранения основаны на консенсусе и требуют большей части для согласованности данных, поэтому двухузловой кластер уязвим для «разделения мозга» и должен рассматриваться как временное состояние при переходе на три или более узлов. Запуск двух узлов может создать доступность или несогласованность данных из двух отдельных наборов данных (одноузловых кластеров), которые перекрываются и не обмениваются данными и не синхронизируют свои данные друг с другом.
Вся конфигурация кластера Dynatrace и его сред (включая все события, пользовательские сеансы и метрики) хранится на каждом узле, поэтому Dynatrace может продолжать работать полностью функционально после потери узла:
- Кластер с тремя узлами может пережить потерю одного узла
- Кластер с пятью и более узлами может выдержать потерю до двух узлов.
Задержка между узлами должна быть около 10 мс или меньше.
Данные событий Log Monitoring v2 реплицируются в хранилище Elasticsearch для достижения высокой доступности и оптимизации затрат на хранение. В результате, если узел выходит из строя, Dynatrace сохраняет резервную копию на другом узле. Однако отказ двух узлов делает некоторые события журнала недоступными. Если узлы вернутся, данные снова будут доступны. В противном случае данные будут потеряны.
Необработанные данные транзакций (стеки вызовов, операторы базы данных, видимость на уровне кода и т. Д.) Не реплицируются между узлами. Он равномерно распределяется по всем узлам. В результате в случае отказа узла Dynatrace может точно оценить недостающие данные. Это возможно, потому что эти данные обычно недолговечны, а большой объем необработанных данных, которые собирает Dynatrace, гарантирует, что каждый узел по-прежнему имеет достаточно большой набор данных, даже если узел недоступен в течение некоторого времени.
Если вы планируете размещать узлы в отдельных центрах обработки данных, не следует развертывать более двух узлов в каждом центре обработки данных. Таким образом, коэффициент репликации, равный трем, гарантирует, что в каждом центре обработки данных будут все данные о показателях и событиях. Кроме того, для бесперебойной работы вам потребуется как минимум три центра обработки данных, один из которых может выйти из строя.
Для установок Dynatrace Managed, развернутых в глобально распределенных центрах обработки данных (с задержкой более 10 мс), вам потребуется повышенная доступность Premium, которая обеспечивает полностью автоматические возможности переключения при отказе в случаях, когда весь центр обработки данных выходит из строя. Это расширяет существующие возможности высокой доступности Dynatrace Managed, чтобы обеспечить географическую избыточность для глобально распределенных предприятий, которым необходимо запускать критически важные службы «под ключ», независимо от решений внешней репликации или балансировки нагрузки.
См. Раздел Высокая доступность для нескольких центров обработки данных.
Аппаратное обеспечение
Чтобы предотвратить потерю данных мониторинга, разверните каждый узел на отдельном физическом диске. Чтобы свести к минимуму потерю производительности, развертывайте узлы в системах с такими же характеристиками оборудования. В случае аппаратного сбоя затрагиваются только данные на отказавшей машине; нет потери данных мониторинга, потому что все узлы реплицируют данные мониторинга. Потеря производительности сведена к минимуму, поскольку все узлы работают на одном и том же типе оборудования с равномерно распределенной рабочей нагрузкой.
Мощность обработки
Постройте свой кластер с учетом дополнительной емкости и возможного отказа узла. Кластеры, которые работают на 100% своей вычислительной мощности, не имеют вычислительной мощности для компенсации потерянного узла и, таким образом, подвержены отбрасыванию данных в случае отказа узла. Развертывания, запланированные на случай отказа узлов, должны иметь вычислительную мощность на треть выше, чем их типичное использование.
Если узел выходит из строя, NGINX, который балансирует нагрузку в системе, автоматически перенаправляет весь трафик OneAgent на оставшиеся рабочие узлы, и нет необходимости в каких-либо действиях пользователя, кроме замены отказавшего узла.
