Механизм аварийного переключения АппОптима - История изменений

IKuznetsov в 09:20, 6 января 2025

2025-01-06T09:20:57Z

← Предыдущая версия		Версия от 09:20, 6 января 2025
Строка 1:		Строка 1:
	'''''[[Установка и настройка]] / Основные элементы АппОптима / АппОптима / Основные понятия / Механизм аварийного переключения АппОптима'''''		'''''[[Установка и настройка]] / [[Установка и настройка\|Основные элементы АппОптима]] / [[АппОптима]] / [[АппОптима\|Основные понятия]] / Механизм аварийного переключения АппОптима'''''

	АппОптима позволяет выполнять развертывание с высокой доступностью в одном или нескольких центрах обработки данных, которые состоят из нескольких одинаково важных узлов, на которых выполняются одни и те же службы.		АппОптима позволяет выполнять развертывание с высокой доступностью в одном или нескольких центрах обработки данных, которые состоят из нескольких одинаково важных узлов, на которых выполняются одни и те же службы.

IKuznetsov в 09:17, 26 декабря 2024

2024-12-26T09:17:27Z

← Предыдущая версия		Версия от 09:17, 26 декабря 2024
Строка 1:		Строка 1:
	'''''[[Установка и настройка]] / Основные элементы АппОптима / [[АппОптима ~~Managed\|АппОптима]]~~ / Основные понятия / Механизм аварийного переключения АппОптима'''''		'''''[[Установка и настройка]] / Основные элементы АппОптима / АппОптима / Основные понятия / Механизм аварийного переключения АппОптима'''''

	АппОптима позволяет выполнять развертывание с высокой доступностью в одном или нескольких центрах обработки данных, которые состоят из нескольких одинаково важных узлов, на которых выполняются одни и те же службы.		АппОптима позволяет выполнять развертывание с высокой доступностью в одном или нескольких центрах обработки данных, которые состоят из нескольких одинаково важных узлов, на которых выполняются одни и те же службы.

IKuznetsov в 10:41, 25 декабря 2024

2024-12-25T10:41:20Z

← Предыдущая версия		Версия от 10:41, 25 декабря 2024
Строка 1:		Строка 1:
	'''''[[Установка и настройка]] / Основные элементы АппОптима / [[АппОптима Managed]] / Основные понятия / Механизм аварийного переключения ~~Managed~~'''''		'''''[[Установка и настройка]] / Основные элементы АппОптима / [[АппОптима Managed\|АппОптима]] / Основные понятия / Механизм аварийного переключения АппОптима'''''

	АппОптима ~~Managed~~ позволяет выполнять развертывание с высокой доступностью в одном или нескольких центрах обработки данных, которые состоят из нескольких одинаково важных узлов, на которых выполняются одни и те же службы.		АппОптима позволяет выполнять развертывание с высокой доступностью в одном или нескольких центрах обработки данных, которые состоят из нескольких одинаково важных узлов, на которых выполняются одни и те же службы.

	Для достижения наилучшего отказоустойчивого развертывания мы рекомендуем следующее:		Для достижения наилучшего отказоустойчивого развертывания мы рекомендуем следующее:
Строка 21:		Строка 21:
	Если вы планируете размещать узлы в отдельных центрах обработки данных, не следует развертывать более двух узлов в каждом из них. Таким образом, коэффициент репликации, равный трем, гарантирует, что в каждом центре обработки данных будут все данные о метриках и событиях. Кроме того, для бесперебойной работы вам потребуется как минимум три центра обработки данных, один из которых может выйти из строя.		Если вы планируете размещать узлы в отдельных центрах обработки данных, не следует развертывать более двух узлов в каждом из них. Таким образом, коэффициент репликации, равный трем, гарантирует, что в каждом центре обработки данных будут все данные о метриках и событиях. Кроме того, для бесперебойной работы вам потребуется как минимум три центра обработки данных, один из которых может выйти из строя.

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

	См. Высокая доступность для нескольких центров обработки данных.		См. Высокая доступность для нескольких центров обработки данных.

IKuznetsov: IKuznetsov переименовал страницу Механизм аварийного переключения Managed в Механизм аварийного переключения АппОптима без оставления перенаправления

2024-12-25T10:08:39Z

IKuznetsov переименовал страницу Механизм аварийного переключения Managed в Механизм аварийного переключения АппОптима без оставления перенаправления

← Предыдущая версия	Версия от 10:08, 25 декабря 2024
(нет различий)

IKuznetsov в 13:08, 8 ноября 2024

2024-11-08T13:08:07Z

ENetrebin в 13:39, 17 августа 2023

2023-08-17T13:39:53Z

← Предыдущая версия		Версия от 13:39, 17 августа 2023
Строка 1:		Строка 1:
			'''''[[Установка и настройка]] / [https://doc.ruscomtech.ru/index.php/%D0%A3%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0_%D0%B8_%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0#.D0.9E.D1.81.D0.BD.D0.BE.D0.B2.D0.BD.D1.8B.D0.B5_.D1.8D.D0.BB.D0.B5.D0.BC.D0.B5.D0.BD.D1.82.D1.8B_.D0.9A.D0.BB.D1.8E.D1.87-.D0.90.D1.81.D1.82.D1.80.D0.BE.D0.BC Основные элементы Ключ-Астром] / [[Ключ-АСТРОМ Managed]] / [https://doc.ruscomtech.ru/index.php/%D0%9A%D0%BB%D1%8E%D1%87-%D0%90%D0%A1%D0%A2%D0%A0%D0%9E%D0%9C_Managed#.D0.9E.D1.81.D0.BD.D0.BE.D0.B2.D0.BD.D1.8B.D0.B5_.D0.BF.D0.BE.D0.BD.D1.8F.D1.82.D0.B8.D1.8F Основные понятия] / Механизм аварийного переключения Managed'''''

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

YaPolkin в 10:16, 7 марта 2022

2022-03-07T10:16:37Z

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

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

YaPolkin в 07:27, 7 марта 2022

2022-03-07T07:27:10Z

← Предыдущая версия		Версия от 07:27, 7 марта 2022
Строка 4:		Строка 4:

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

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

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

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

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

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

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

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

	См. ~~Раздел~~ Высокая доступность для нескольких центров обработки данных.

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

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

YaPolkin в 17:08, 4 декабря 2021

2021-12-04T17:08:21Z

YaPolkin: Новая страница: «Dynatrace Managed позволяет выполнять развертывание с высокой доступностью в одном или несколь...»

2021-12-01T03:20:45Z

Новая страница: «Dynatrace Managed позволяет выполнять развертывание с высокой доступностью в одном или несколь...»

Новая страница

Dynatrace Managed позволяет выполнять развертывание с высокой доступностью в одном или нескольких центрах обработки данных, которые состоят из нескольких одинаково важных узлов, на которых выполняются одни и те же службы.

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

=== Резервирование ===
Запланируйте развертывание минимум трех узлов на кластер. В таких кластерах все узлы автоматически реплицируют данные между узлами, поэтому обычно есть две реплики в дополнение к первичному осколку.
----Избегайте проблем с синхронизацией разделенного мозга

Хотя кластеры с двумя узлами технически возможны, мы не рекомендуем этого делать. Наши системы хранения основаны на консенсусе и требуют большей части для согласованности данных, поэтому двухузловой кластер уязвим для «разделения мозга» и должен рассматриваться как временное состояние при переходе на три или более узлов. Запуск двух узлов может создать доступность или несогласованность данных из двух отдельных наборов данных (одноузловых кластеров), которые перекрываются и не обмениваются данными и не синхронизируют свои данные друг с другом.
----Вся конфигурация кластера Dynatrace и его сред (включая все события, пользовательские сеансы и метрики) хранится на каждом узле, поэтому Dynatrace может продолжать работать полностью функционально после потери узла:

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

Задержка между узлами должна быть около 10 мс или меньше.

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

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

Если вы планируете размещать узлы в отдельных центрах обработки данных, не следует развертывать более двух узлов в каждом центре обработки данных. Таким образом, коэффициент репликации, равный трем, гарантирует, что в каждом центре обработки данных будут все данные о показателях и событиях. Кроме того, для бесперебойной работы вам потребуется как минимум три центра обработки данных, один из которых может выйти из строя.

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

См. Раздел Высокая доступность для нескольких центров обработки данных.

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

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

← Предыдущая версия		Версия от 13:08, 8 ноября 2024
Строка 1:		Строка 1:
	'''''[[Установка и настройка]] / [https://doc.ruscomtech.ru/index.php/%D0%A3%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0_%D0%B8_%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0#.D0.9E.D1.81.D0.BD.D0.BE.D0.B2.D0.BD.D1.8B.D0.B5_.D1.8D.D0.BB.D0.B5.D0.BC.D0.B5.D0.BD.D1.82.D1.8B_.D0.9A.D0.BB.D1.8E.D1.87-.D0.90.D1.81.D1.82.D1.80.D0.BE.D0.BC Основные элементы ~~Ключ-Астром]~~ / [[~~Ключ-АСТРОМ~~ Managed]] / ~~[https://doc.ruscomtech.ru/index.php/%D0%9A%D0%BB%D1%8E%D1%87-%D0%90%D0%A1%D0%A2%D0%A0%D0%9E%D0%9C_Managed#.D0.9E.D1.81.D0.BD.D0.BE.D0.B2.D0.BD.D1.8B.D0.B5_.D0.BF.D0.BE.D0.BD.D1.8F.D1.82.D0.B8.D1.8F~~ Основные понятия] / Механизм аварийного переключения Managed'''''		'''''[[Установка и настройка]] / Основные элементы АппОптима / [[АппОптима Managed]] / Основные понятия / Механизм аварийного переключения Managed'''''

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

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

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

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

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

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

	Если вы планируете размещать узлы в отдельных центрах обработки данных, не следует развертывать более двух узлов в каждом из них. Таким образом, коэффициент репликации, равный трем, гарантирует, что в каждом центре обработки данных будут все данные о метриках и событиях. Кроме того, для бесперебойной работы вам потребуется как минимум три центра обработки данных, один из которых может выйти из строя.		Если вы планируете размещать узлы в отдельных центрах обработки данных, не следует развертывать более двух узлов в каждом из них. Таким образом, коэффициент репликации, равный трем, гарантирует, что в каждом центре обработки данных будут все данные о метриках и событиях. Кроме того, для бесперебойной работы вам потребуется как минимум три центра обработки данных, один из которых может выйти из строя.

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

	См. Высокая доступность для нескольких центров обработки данных.		См. Высокая доступность для нескольких центров обработки данных.

← Предыдущая версия		Версия от 17:08, 4 декабря 2021
Строка 1:		Строка 1:
	~~Dynatrace~~ Managed позволяет выполнять развертывание с высокой доступностью в одном или нескольких центрах обработки данных, которые состоят из нескольких одинаково важных узлов, на которых выполняются одни и те же службы.		Ключ-АСТРОМ Managed позволяет выполнять развертывание с высокой доступностью в одном или нескольких центрах обработки данных, которые состоят из нескольких одинаково важных узлов, на которых выполняются одни и те же службы.

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

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

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

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

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

	Если вы планируете размещать узлы в отдельных центрах обработки данных, не следует развертывать более двух узлов в каждом центре обработки данных. Таким образом, коэффициент репликации, равный трем, гарантирует, что в каждом центре обработки данных будут все данные о показателях и событиях. Кроме того, для бесперебойной работы вам потребуется как минимум три центра обработки данных, один из которых может выйти из строя.		Если вы планируете размещать узлы в отдельных центрах обработки данных, не следует развертывать более двух узлов в каждом центре обработки данных. Таким образом, коэффициент репликации, равный трем, гарантирует, что в каждом центре обработки данных будут все данные о показателях и событиях. Кроме того, для бесперебойной работы вам потребуется как минимум три центра обработки данных, один из которых может выйти из строя.

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

	См. Раздел Высокая доступность для нескольких центров обработки данных.		См. Раздел Высокая доступность для нескольких центров обработки данных.
Строка 30:		Строка 30:
	=== Мощность обработки ===		=== Мощность обработки ===
	Постройте свой кластер с учетом дополнительной емкости и возможного отказа узла. Кластеры, которые работают на 100% своей вычислительной мощности, не имеют вычислительной мощности для компенсации потерянного узла и, таким образом, подвержены отбрасыванию данных в случае отказа узла. Развертывания, запланированные на случай отказа узлов, должны иметь вычислительную мощность на треть выше, чем их типичное использование.		Постройте свой кластер с учетом дополнительной емкости и возможного отказа узла. Кластеры, которые работают на 100% своей вычислительной мощности, не имеют вычислительной мощности для компенсации потерянного узла и, таким образом, подвержены отбрасыванию данных в случае отказа узла. Развертывания, запланированные на случай отказа узлов, должны иметь вычислительную мощность на треть выше, чем их типичное использование.
	----Если узел выходит из строя, NGINX, который балансирует нагрузку в системе, автоматически перенаправляет весь трафик ~~OneAgent~~ на оставшиеся рабочие узлы, и нет необходимости в каких-либо действиях пользователя, кроме замены отказавшего узла.		----Если узел выходит из строя, NGINX, который балансирует нагрузку в системе, автоматически перенаправляет весь трафик ЕдиныйАгент на оставшиеся рабочие узлы, и нет необходимости в каких-либо действиях пользователя, кроме замены отказавшего узла.