Механизм аварийного переключения Managed: различия между версиями
YaPolkin (обсуждение | вклад) (Новая страница: «Dynatrace Managed позволяет выполнять развертывание с высокой доступностью в одном или несколь...») |
YaPolkin (обсуждение | вклад) |
||
| (не показаны 3 промежуточные версии этого же участника) | |||
| Строка 4: | Строка 4: | ||
=== Резервирование === | === Резервирование === | ||
Запланируйте развертывание минимум трех узлов на кластер. В таких кластерах все узлы автоматически реплицируют данные между узлами, поэтому обычно есть две реплики в дополнение к первичному | Запланируйте развертывание минимум трех узлов на кластер. В таких кластерах все узлы автоматически реплицируют данные между узлами, поэтому обычно есть две реплики в дополнение к первичному шарду. | ||
----Избегайте проблем с синхронизацией | ----<blockquote>''<big>Избегайте проблем с синхронизацией split-brain</big>'' | ||
Хотя кластеры с двумя узлами технически возможны, мы не рекомендуем этого делать. Наши системы хранения основаны на консенсусе и требуют большей части для согласованности данных, поэтому двухузловой кластер уязвим для | Хотя кластеры с двумя узлами технически возможны, мы не рекомендуем этого делать. Наши системы хранения основаны на консенсусе и требуют большей части для согласованности данных, поэтому двухузловой кластер уязвим для split-brain и должен рассматриваться как временное состояние при переходе на три или более узлов. Запуск двух узлов может создать несогласованность доступности или данных из двух отдельных наборов данных (одноузловых кластеров), которые перекрываются и не обмениваются данными и не синхронизируют свои данные друг с другом.</blockquote> | ||
----Вся конфигурация кластера Dynatrace и его сред (включая все события, пользовательские сеансы и метрики) хранится на каждом узле, поэтому Dynatrace может продолжать работать полностью функционально после потери узла: | ----Вся конфигурация кластера Dynatrace и его сред (включая все события, пользовательские сеансы и метрики) хранится на каждом узле, поэтому Dynatrace может продолжать работать полностью функционально после потери узла: | ||
* Кластер с тремя узлами может пережить потерю одного узла | * Кластер с тремя узлами может пережить потерю одного узла | ||
* Кластер с пятью | * Кластер с пятью или более узлами может пережить потерю до двух узлов. Задержка между узлами должна составлять около 10 мс или меньше. | ||
Данные событий Log Monitoring v2 реплицируются в хранилище Elasticsearch для достижения высокой доступности и оптимизации затрат хранилища. В результате, если узел выходит из строя, Dynatrace сохраняет резервную копию на другом узле. Однако отказ двух узлов делает некоторые события журнала недоступными. Если узлы вернутся, данные снова будут доступны. В противном случае данные будут потеряны. | |||
Необработанные данные транзакций (стеки вызовов, операторы базы данных, видимость на уровне кода и т.д.) не реплицируются между узлами. Они равномерно распределяется по всем узлам. В результате в случае отказа узла Dynatrace может точно оценить недостающие данные. Это возможно, потому что эти данные обычно недолговечны, а большой объем необработанных данных, которые собирает Dynatrace, гарантирует, что каждый узел по-прежнему имеет достаточно большой набор данных, даже если узел недоступен в течение некоторого времени. | |||
Если вы планируете размещать узлы в отдельных центрах обработки данных, не следует развертывать более двух узлов в каждом из них. Таким образом, коэффициент репликации, равный трем, гарантирует, что в каждом центре обработки данных будут все данные о метриках и событиях. Кроме того, для бесперебойной работы вам потребуется как минимум три центра обработки данных, один из которых может выйти из строя. | |||
Для установок Dynatrace Managed, развернутых в глобально распределенных центрах обработки данных (с задержкой более 10 мс), вам потребуется Премиум высокой доступности, которая обеспечивает полностью автоматические возможности переключения при отказе в случаях, когда весь центр обработки данных выходит из строя. Это расширяет существующие возможности высокой доступности Dynatrace Managed, чтобы обеспечить географическую избыточность для глобально распределенных предприятий, которым необходимо запускать критически важные службы «под ключ», независимо от решений внешней репликации или балансировки нагрузки. | |||
См. Высокая доступность для нескольких центров обработки данных. | |||
См. | |||
=== Аппаратное обеспечение === | === Аппаратное обеспечение === | ||
Чтобы предотвратить потерю данных мониторинга, разверните каждый узел на отдельном физическом диске. Чтобы свести к минимуму потерю производительности, развертывайте узлы в системах с | Чтобы предотвратить потерю данных мониторинга, разверните каждый узел на отдельном физическом диске. Чтобы свести к минимуму потерю производительности, развертывайте узлы в системах с одинаковыми характеристиками оборудования. В случае аппаратного сбоя затрагиваются только данные на отказавшей машине; нет потери данных мониторинга, потому что все узлы реплицируют данные мониторинга. Потеря производительности сведена к минимуму, поскольку все узлы работают на одном и том же типе оборудования с равномерно распределенной рабочей нагрузкой. | ||
=== Мощность обработки === | === Мощность обработки === | ||
Постройте свой кластер с учетом дополнительной емкости и возможного отказа узла. Кластеры, которые работают на 100% своей вычислительной мощности, не имеют вычислительной мощности для компенсации потерянного узла и, таким образом, подвержены отбрасыванию данных в случае отказа узла. Развертывания, запланированные на случай отказа узлов, должны иметь вычислительную мощность на треть выше, чем их типичное использование. | Постройте свой кластер с учетом дополнительной емкости и возможного отказа узла. Кластеры, которые работают на 100% своей вычислительной мощности, не имеют вычислительной мощности для компенсации потерянного узла и, таким образом, подвержены отбрасыванию данных в случае отказа узла. Развертывания, запланированные на случай отказа узлов, должны иметь вычислительную мощность на треть выше, чем их типичное использование. | ||
----Если узел выходит из строя, NGINX, который балансирует нагрузку в системе, автоматически перенаправляет весь трафик OneAgent на оставшиеся рабочие узлы, и нет необходимости в каких-либо действиях пользователя, кроме замены отказавшего узла. | ----Если узел выходит из строя, NGINX, который балансирует нагрузку в системе, автоматически перенаправляет весь трафик OneAgent на оставшиеся рабочие узлы, и нет необходимости в каких-либо действиях пользователя, кроме замены отказавшего узла. | ||
Текущая версия на 09:36, 20 января 2023
Dynatrace Managed позволяет выполнять развертывание с высокой доступностью в одном или нескольких центрах обработки данных, которые состоят из нескольких одинаково важных узлов, на которых выполняются одни и те же службы.
Для достижения наилучшего отказоустойчивого развертывания мы рекомендуем следующее:
Резервирование
Запланируйте развертывание минимум трех узлов на кластер. В таких кластерах все узлы автоматически реплицируют данные между узлами, поэтому обычно есть две реплики в дополнение к первичному шарду.
Избегайте проблем с синхронизацией split-brain Хотя кластеры с двумя узлами технически возможны, мы не рекомендуем этого делать. Наши системы хранения основаны на консенсусе и требуют большей части для согласованности данных, поэтому двухузловой кластер уязвим для split-brain и должен рассматриваться как временное состояние при переходе на три или более узлов. Запуск двух узлов может создать несогласованность доступности или данных из двух отдельных наборов данных (одноузловых кластеров), которые перекрываются и не обмениваются данными и не синхронизируют свои данные друг с другом.
Вся конфигурация кластера Dynatrace и его сред (включая все события, пользовательские сеансы и метрики) хранится на каждом узле, поэтому Dynatrace может продолжать работать полностью функционально после потери узла:
- Кластер с тремя узлами может пережить потерю одного узла
- Кластер с пятью или более узлами может пережить потерю до двух узлов. Задержка между узлами должна составлять около 10 мс или меньше.
Данные событий Log Monitoring v2 реплицируются в хранилище Elasticsearch для достижения высокой доступности и оптимизации затрат хранилища. В результате, если узел выходит из строя, Dynatrace сохраняет резервную копию на другом узле. Однако отказ двух узлов делает некоторые события журнала недоступными. Если узлы вернутся, данные снова будут доступны. В противном случае данные будут потеряны.
Необработанные данные транзакций (стеки вызовов, операторы базы данных, видимость на уровне кода и т.д.) не реплицируются между узлами. Они равномерно распределяется по всем узлам. В результате в случае отказа узла Dynatrace может точно оценить недостающие данные. Это возможно, потому что эти данные обычно недолговечны, а большой объем необработанных данных, которые собирает Dynatrace, гарантирует, что каждый узел по-прежнему имеет достаточно большой набор данных, даже если узел недоступен в течение некоторого времени.
Если вы планируете размещать узлы в отдельных центрах обработки данных, не следует развертывать более двух узлов в каждом из них. Таким образом, коэффициент репликации, равный трем, гарантирует, что в каждом центре обработки данных будут все данные о метриках и событиях. Кроме того, для бесперебойной работы вам потребуется как минимум три центра обработки данных, один из которых может выйти из строя.
Для установок Dynatrace Managed, развернутых в глобально распределенных центрах обработки данных (с задержкой более 10 мс), вам потребуется Премиум высокой доступности, которая обеспечивает полностью автоматические возможности переключения при отказе в случаях, когда весь центр обработки данных выходит из строя. Это расширяет существующие возможности высокой доступности Dynatrace Managed, чтобы обеспечить географическую избыточность для глобально распределенных предприятий, которым необходимо запускать критически важные службы «под ключ», независимо от решений внешней репликации или балансировки нагрузки.
См. Высокая доступность для нескольких центров обработки данных.
Аппаратное обеспечение
Чтобы предотвратить потерю данных мониторинга, разверните каждый узел на отдельном физическом диске. Чтобы свести к минимуму потерю производительности, развертывайте узлы в системах с одинаковыми характеристиками оборудования. В случае аппаратного сбоя затрагиваются только данные на отказавшей машине; нет потери данных мониторинга, потому что все узлы реплицируют данные мониторинга. Потеря производительности сведена к минимуму, поскольку все узлы работают на одном и том же типе оборудования с равномерно распределенной рабочей нагрузкой.
Мощность обработки
Постройте свой кластер с учетом дополнительной емкости и возможного отказа узла. Кластеры, которые работают на 100% своей вычислительной мощности, не имеют вычислительной мощности для компенсации потерянного узла и, таким образом, подвержены отбрасыванию данных в случае отказа узла. Развертывания, запланированные на случай отказа узлов, должны иметь вычислительную мощность на треть выше, чем их типичное использование.
Если узел выходит из строя, NGINX, который балансирует нагрузку в системе, автоматически перенаправляет весь трафик OneAgent на оставшиеся рабочие узлы, и нет необходимости в каких-либо действиях пользователя, кроме замены отказавшего узла.
