Механизм аварийного переключения Managed: различия между версиями

Материал из Dynatrace
 
(не показаны 2 промежуточные версии этого же участника)
Строка 1: Строка 1:
Ключ-АСТРОМ Managed позволяет выполнять развертывание с высокой доступностью в одном или нескольких центрах обработки данных, которые состоят из нескольких одинаково важных узлов, на которых выполняются одни и те же службы.
Dynatrace Managed позволяет выполнять развертывание с высокой доступностью в одном или нескольких центрах обработки данных, которые состоят из нескольких одинаково важных узлов, на которых выполняются одни и те же службы.


Для достижения наилучшего отказоустойчивого развертывания мы рекомендуем следующее:
Для достижения наилучшего отказоустойчивого развертывания мы рекомендуем следующее:


=== Резервирование ===
=== Резервирование ===
Запланируйте развертывание минимум трех узлов на кластер. В таких кластерах все узлы автоматически реплицируют данные между узлами, поэтому обычно есть две реплики в дополнение к первичному осколку.
Запланируйте развертывание минимум трех узлов на кластер. В таких кластерах все узлы автоматически реплицируют данные между узлами, поэтому обычно есть две реплики в дополнение к первичному шарду.
----Избегайте проблем с синхронизацией разделенного мозга
----<blockquote>''<big>Избегайте проблем с синхронизацией split-brain</big>''


Хотя кластеры с двумя узлами технически возможны, мы не рекомендуем этого делать. Наши системы хранения основаны на консенсусе и требуют большей части для согласованности данных, поэтому двухузловой кластер уязвим для «разделения мозга» и должен рассматриваться как временное состояние при переходе на три или более узлов. Запуск двух узлов может создать доступность или несогласованность данных из двух отдельных наборов данных (одноузловых кластеров), которые перекрываются и не обмениваются данными и не синхронизируют свои данные друг с другом.
Хотя кластеры с двумя узлами технически возможны, мы не рекомендуем этого делать. Наши системы хранения основаны на консенсусе и требуют большей части для согласованности данных, поэтому двухузловой кластер уязвим для split-brain и должен рассматриваться как временное состояние при переходе на три или более узлов. Запуск двух узлов может создать несогласованность доступности или данных из двух отдельных наборов данных (одноузловых кластеров), которые перекрываются и не обмениваются данными и не синхронизируют свои данные друг с другом.</blockquote>
----Вся конфигурация кластера Ключ-АСТРОМ и его сред (включая все события, пользовательские сеансы и метрики) хранится на каждом узле, поэтому Ключ-АСТРОМ может продолжать работать полностью функционально после потери узла:
----Вся конфигурация кластера Dynatrace и его сред (включая все события, пользовательские сеансы и метрики) хранится на каждом узле, поэтому Dynatrace может продолжать работать полностью функционально после потери узла:


* Кластер с тремя узлами может пережить потерю одного узла
* Кластер с тремя узлами может пережить потерю одного узла
* Кластер с пятью и более узлами может выдержать потерю до двух узлов.
* Кластер с пятью или более узлами может пережить потерю до двух узлов. Задержка между узлами должна составлять около 10 мс или меньше.


Задержка между узлами должна быть около 10 мс или меньше.
Данные событий Log Monitoring v2 реплицируются в хранилище Elasticsearch для достижения высокой доступности и оптимизации затрат хранилища. В результате, если узел выходит из строя, Dynatrace сохраняет резервную копию на другом узле. Однако отказ двух узлов делает некоторые события журнала недоступными. Если узлы вернутся, данные снова будут доступны. В противном случае данные будут потеряны.


Данные событий Log Monitoring v2 реплицируются в хранилище Elasticsearch для достижения высокой доступности и оптимизации затрат на хранение. В результате, если узел выходит из строя, Ключ-АСТРОМ сохраняет резервную копию на другом узле. Однако отказ двух узлов делает некоторые события журнала недоступными. Если узлы вернутся, данные снова будут доступны. В противном случае данные будут потеряны.
Необработанные данные транзакций (стеки вызовов, операторы базы данных, видимость на уровне кода и т.д.) не реплицируются между узлами. Они равномерно распределяется по всем узлам. В результате в случае отказа узла Dynatrace может точно оценить недостающие данные. Это возможно, потому что эти данные обычно недолговечны, а большой объем необработанных данных, которые собирает Dynatrace, гарантирует, что каждый узел по-прежнему имеет достаточно большой набор данных, даже если узел недоступен в течение некоторого времени.


Необработанные данные транзакций (стеки вызовов, операторы базы данных, видимость на уровне кода и т. Д.) Не реплицируются между узлами. Он равномерно распределяется по всем узлам. В результате в случае отказа узла Ключ-АСТРОМ может точно оценить недостающие данные. Это возможно, потому что эти данные обычно недолговечны, а большой объем необработанных данных, которые собирает Ключ-АСТРОМ, гарантирует, что каждый узел по-прежнему имеет достаточно большой набор данных, даже если узел недоступен в течение некоторого времени.
Если вы планируете размещать узлы в отдельных центрах обработки данных, не следует развертывать более двух узлов в каждом из них. Таким образом, коэффициент репликации, равный трем, гарантирует, что в каждом центре обработки данных будут все данные о метриках и событиях. Кроме того, для бесперебойной работы вам потребуется как минимум три центра обработки данных, один из которых может выйти из строя.


Если вы планируете размещать узлы в отдельных центрах обработки данных, не следует развертывать более двух узлов в каждом центре обработки данных. Таким образом, коэффициент репликации, равный трем, гарантирует, что в каждом центре обработки данных будут все данные о показателях и событиях. Кроме того, для бесперебойной работы вам потребуется как минимум три центра обработки данных, один из которых может выйти из строя.
Для установок Dynatrace Managed, развернутых в глобально распределенных центрах обработки данных (с задержкой более 10 мс), вам потребуется Премиум высокой доступности, которая обеспечивает полностью автоматические возможности переключения при отказе в случаях, когда весь центр обработки данных выходит из строя. Это расширяет существующие возможности высокой доступности Dynatrace Managed, чтобы обеспечить географическую избыточность для глобально распределенных предприятий, которым необходимо запускать критически важные службы «под ключ», независимо от решений внешней репликации или балансировки нагрузки.


Для установок Ключ-АСТРОМ Managed, развернутых в глобально распределенных центрах обработки данных (с задержкой более 10 мс), вам потребуется повышенная доступность Premium, которая обеспечивает полностью автоматические возможности переключения при отказе в случаях, когда весь центр обработки данных выходит из строя. Это расширяет существующие возможности высокой доступности Ключ-АСТРОМ Managed, чтобы обеспечить географическую избыточность для глобально распределенных предприятий, которым необходимо запускать критически важные службы «под ключ», независимо от решений внешней репликации или балансировки нагрузки.
См. Высокая доступность для нескольких центров обработки данных.
 
См. Раздел Высокая доступность для нескольких центров обработки данных.


=== Аппаратное обеспечение ===
=== Аппаратное обеспечение ===
Чтобы предотвратить потерю данных мониторинга, разверните каждый узел на отдельном физическом диске. Чтобы свести к минимуму потерю производительности, развертывайте узлы в системах с такими же характеристиками оборудования. В случае аппаратного сбоя затрагиваются только данные на отказавшей машине; нет потери данных мониторинга, потому что все узлы реплицируют данные мониторинга. Потеря производительности сведена к минимуму, поскольку все узлы работают на одном и том же типе оборудования с равномерно распределенной рабочей нагрузкой.
Чтобы предотвратить потерю данных мониторинга, разверните каждый узел на отдельном физическом диске. Чтобы свести к минимуму потерю производительности, развертывайте узлы в системах с одинаковыми характеристиками оборудования. В случае аппаратного сбоя затрагиваются только данные на отказавшей машине; нет потери данных мониторинга, потому что все узлы реплицируют данные мониторинга. Потеря производительности сведена к минимуму, поскольку все узлы работают на одном и том же типе оборудования с равномерно распределенной рабочей нагрузкой.


=== Мощность обработки ===
=== Мощность обработки ===
Постройте свой кластер с учетом дополнительной емкости и возможного отказа узла. Кластеры, которые работают на 100% своей вычислительной мощности, не имеют вычислительной мощности для компенсации потерянного узла и, таким образом, подвержены отбрасыванию данных в случае отказа узла. Развертывания, запланированные на случай отказа узлов, должны иметь вычислительную мощность на треть выше, чем их типичное использование.
Постройте свой кластер с учетом дополнительной емкости и возможного отказа узла. Кластеры, которые работают на 100% своей вычислительной мощности, не имеют вычислительной мощности для компенсации потерянного узла и, таким образом, подвержены отбрасыванию данных в случае отказа узла. Развертывания, запланированные на случай отказа узлов, должны иметь вычислительную мощность на треть выше, чем их типичное использование.
----Если узел выходит из строя, NGINX, который балансирует нагрузку в системе, автоматически перенаправляет весь трафик ЕдиныйАгент на оставшиеся рабочие узлы, и нет необходимости в каких-либо действиях пользователя, кроме замены отказавшего узла.
----Если узел выходит из строя, 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 на оставшиеся рабочие узлы, и нет необходимости в каких-либо действиях пользователя, кроме замены отказавшего узла.