Требования Managed к оборудованию - История изменений

YaPolkin в 09:41, 20 января 2023

2023-01-20T09:41:50Z

Lobanov: /* Рекомендации по хранилищу */

2022-03-15T17:25:15Z

Рекомендации по хранилищу

← Предыдущая		Версия 17:25, 15 марта 2022
Строка 216:		Строка 216:
	\|-		\|-
	\|PRODUCT_PATH		\|PRODUCT_PATH
	\|<code>/opt/~~dynatrace~~-managed</code>		\|<code>/opt/<namespace>-managed</code>
	\|Главный каталог для двоичных файлов Ключ-АСТРОМ Managed		\|Главный каталог для двоичных файлов Ключ-АСТРОМ Managed
	\|7 ГБ		\|7 ГБ
Строка 222:		Строка 222:
	\|-		\|-
	\|DATASTORE_PATH		\|DATASTORE_PATH
	\|<code>/var/opt/~~dynatrace~~-managed</code>		\|<code>/var/opt/<namespace>-managed</code>
	\|Главный каталог для данных Ключ-АСТРОМ Managed		\|Главный каталог для данных Ключ-АСТРОМ Managed
	\|24 ГБ		\|24 ГБ
Строка 272:		Строка 272:

	Также см. Дисковое пространство для ЕдиногоАгента		Также см. Дисковое пространство для ЕдиногоАгента
	\|<code>/opt/~~dynatrace~~</code>		\|<code>/opt/<namespace></code>
	\|Главный каталог для самоконтроля двоичных файлов ЕдиногоАгента.		\|Главный каталог для самоконтроля двоичных файлов ЕдиногоАгента.
	\|4.8 ГБ		\|4.8 ГБ

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

2022-03-07T10:14:42Z

YaPolkin в 06:56, 7 марта 2022

2022-03-07T06:56:53Z

Внесённые изменения

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

2021-12-04T17:12:10Z

← Предыдущая		Версия 17:12, 4 декабря 2021
Строка 262:		Строка 262:
	\|AGENT_BUILD_UNITS_PATH		\|AGENT_BUILD_UNITS_PATH
	\|DATASTORE_PATH/agents		\|DATASTORE_PATH/agents
	\|Установочные пакеты ЕдиныйАгент и ~~ActiveGate~~ (если они загружены сервером ЕдиныйАгент или установлены из отдельных пакетов)		\|Установочные пакеты ЕдиныйАгент и АктивныйШлюз (если они загружены сервером ЕдиныйАгент или установлены из отдельных пакетов)
	\|20 GB		\|20 GB
	\|1 GB		\|1 GB

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

2021-12-04T17:11:45Z

Внесённые изменения

YaPolkin: /* Рекомендации Log Monitoring v2 */

2021-12-02T00:02:58Z

Рекомендации Log Monitoring v2

← Предыдущая		Версия 00:02, 2 декабря 2021
Строка 307:		Строка 307:
	Например, для обработки трехсот миллионов (300 000 000) событий журнала в день вам потребуются дополнительные 15 ЦП, 9,9 ТБ диска и 19,5 ГБ ОЗУ. В существующем кластере из трех узлов среднего размера вы можете выполнить одно из следующих действий:		Например, для обработки трехсот миллионов (300 000 000) событий журнала в день вам потребуются дополнительные 15 ЦП, 9,9 ТБ диска и 19,5 ГБ ОЗУ. В существующем кластере из трех узлов среднего размера вы можете выполнить одно из следующих действий:

	* <~~!--~~ рекомендуется --> Добавить два дополнительных узла среднего размера, чтобы сформировать кластер из пяти узлов. Кроме того, увеличьте хранилище Elasticsearh на каждом узле на 2 ТБ (в этом случае каждый узел хранит 40% дважды реплицированных данных).		* <u>[рекомендуется]</u> Добавить два дополнительных узла среднего размера, чтобы сформировать кластер из пяти узлов. Кроме того, увеличьте хранилище Elasticsearh на каждом узле на 2 ТБ (в этом случае каждый узел хранит 40% дважды реплицированных данных).

	* Добавьте 3,3 ТБ дискового хранилища (каждый узел хранит 67% дважды реплицированных данных), 8 ЦП и 16 ГБ ОЗУ на каждый узел.		* Добавьте 3,3 ТБ дискового хранилища (каждый узел хранит 67% дважды реплицированных данных), 8 ЦП и 16 ГБ ОЗУ на каждый узел.

YaPolkin: Новая страница: «В этом разделе объясняется оборудование для установки Dynatrace Managed. Другие требования Dynatrac...»

2021-12-01T22:30:41Z

Новая страница: «В этом разделе объясняется оборудование для установки Dynatrace Managed. Другие требования Dynatrac...»

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

В этом разделе объясняется оборудование для установки Dynatrace Managed. Другие требования Dynatrace Managed см. в разделах Требования к управляемой системе и Рекомендации по управляемому оборудованию для облачных развертываний.
----<big>''Соображения по размеру''</big>

Калибровка обычно состоит из следующих элементов:

* Генеральная планировка
* Требования к оборудованию
* Рекомендации по хранению
* Рекомендации Log Monitoring 2.0

Обязательно изучите каждый элемент, прежде чем продолжить.
----

== Генеральная планировка ==
Не всегда возможно подготовить узлы с точным размером, особенно если ваша среда подвержена постоянно растущим уровням трафика. Хотя предварительный анализ необходимого размера полезен, важнее иметь возможность увеличить емкость управляемого кластера Dynatrace, если в будущем потребности в мониторинге возрастут. Чтобы воспользоваться всеми преимуществами управляемой архитектуры Dynatrace, будьте готовы к масштабированию по следующим параметрам:

* По горизонтали, добавив больше узлов. Мы поддерживаем установку до 30 узлов кластера.
* Вертикально за счет выделения большего количества ОЗУ / ЦП на узел.
* Что касается хранения данных, то есть возможность изменять размер дисковых томов по мере необходимости (рекомендации по рекомендуемой настройке дисков см. Ниже).

Для облачных развертываний используйте рекомендованные эквиваленты виртуальных машин для рекомендаций по управляемому оборудованию для облачных развертываний

== Требования к оборудованию ==
Требования к оборудованию, приведенные в следующей таблице, являются приблизительными, основанными на типичных средах и схемах нагрузки. Требования для отдельных сред могут отличаться. При оценке конкретных столбцов учитывается следующее:

* Минимальные технические характеристики узла
** ЦП и ОЗУ должны быть доступны исключительно для Dynatrace. Режим энергосбережения для ЦП должен быть отключен. Процессоры должны работать с тактовой частотой не менее 2 ГГц, а хосту должно быть назначено не менее 32 ГБ ОЗУ.

* Хранение транзакций
** Данные транзакции распределяются по всем узлам и не хранятся избыточно. В кластерах с несколькими узлами хранение данных транзакций делится на количество узлов.

* Магазин долгосрочных показателей
** Для многоузловых установок сохраняются три копии хранилища метрик. Для четырех или более узлов требования к хранилищу на каждый узел снижаются.

Требование 4 ТБ для узла XLarge следует рассматривать как максимально допустимый размер. Если вам нужна дополнительная емкость, подумайте о добавлении еще одного узла. Планируйте свое хранилище долгосрочных метрик так, чтобы данные занимали не более 50% доступного дискового пространства. Таким образом, 4 ТБ пространства будут обрабатывать 2 ТБ данных вашего долгосрочного хранилища метрик. Хотя возможны хранилища размером более 4 ТБ, они могут затруднить обслуживание базы данных.

=== Ключ-АСТРОМ Managed ===
{| class="wikitable"
!Тип узла
!Макс хостов

под наблюдением

(на узел)
!Максимальный пользователь

действий / мин

(на узел)
!Мин узел

технические характеристики
!Диск IOPS

(на узел)
!Хранение транзакций

(Видимость кода 10 дней)
!Долгосрочное

Магазин метрик

(на узел)
!Elasticsearch

(на узел)

(Срок хранения 35 дней)
|-
|Микро
|50
|1000
|4 vCPUs,
32 GB RAM
|500
|50 GB
|100 GB
|50 GB
|-
|Небольшой
|300
|10000
|8 vCPUs,
64 GB RAM
|3000
|300 GB
|500 GB
|500 GB
|-
|Средний
|600
|25000
|16 vCPUs,
128 GB RAM
|5000
|600 GB
|1 TB
|1.5 TB
|-
|Большой
|1250
|50000
|32 vCPUs,
256 GB RAM
|7500
|1 TB
|2 TB
|1.5 TB
|-
|XБольшой1
|2500
|100000
|64 vCPUs,
512 GB RAM
|10000
|2 TB
|4 TB
|3 TB
|}
1 Хотя Dynatrace Managed устойчиво работает на инстансах с 1 ТБ + ОЗУ / 128 ядрами (2XLarge) и позволяет отслеживать больше объектов, это не оптимальный способ использования оборудования. Вместо этого мы рекомендуем использовать экземпляры меньшего размера (Large или XLarge).

==== Примеры ====

* Чтобы контролировать до 7500 хостов с пиковой нагрузкой 300 000 действий пользователя в минуту, вам понадобятся 3 очень больших (XLarge) узла с объемом хранилища 9 ТБ каждый, разделенный на типы хранилищ.
* Для мониторинга 500 хостов с пиковой нагрузкой 30 000 действий пользователя в минуту вам потребуется 3 небольших узла с объемом хранилища 1,3 ТБ каждый, разделенный на типы хранилищ соответственно. В качестве альтернативы вы также можете использовать 1 средний узел с объемом хранилища 2,1 ТБ. Мы рекомендуем настроить аварийное переключение минимум на 3 узла вместо одиночных узлов, которые менее устойчивы.

=== Ключ-АСТРОМ Managed Premium High Availability ===
{| class="wikitable"
!Тип узла
!Макс хостов

под наблюдением

(на узел)
!Максимальный пользователь

действий / мин

(на узел)
!Мин узел

технические характеристики
!Диск IOPS

(на узел)
!Хранение транзакций

(Видимость кода 10 дней)
!Долгосрочное

Магазин метрик

(на узел)
!Elasticsearch

(на узел)

(Срок хранения 35 дней)
|-
|Большой
|600
|25000
|32 vCPUs,
256 GB RAM
|7500
|1 TB
|2 TB
|1.5 TB
|-
|XБольшой1
|1250
|50000
|64 vCPUs,
512 GB RAM
|10000
|2 TB
|4 TB
|3 TB
|}
1 Хотя Dynatrace Managed устойчиво работает на инстансах с 1 ТБ + ОЗУ / 128 ядрами (2XLarge) и позволяет отслеживать больше объектов, это не оптимальный способ использования оборудования. Вместо этого мы рекомендуем использовать экземпляры меньшего размера (Large или XLarge).

==== Пример ====
Для мониторинга 7500 хостов с пиковой нагрузкой 300000 действий пользователя в минуту в развертывании Premium High Availability вам потребуется 6 очень больших (XLarge) узлов - 3 узла в одном центре обработки данных и 3 узла во втором центре обработки данных, каждый узел с хранилищем 9 ТБ, разделенных соответственно на типы хранилищ.

== Рекомендации по хранению ==
Dynatrace Managed хранит несколько типов данных мониторинга в зависимости от варианта использования.

Мы рекомендуем:

* Хранение двоичных файлов Dynatrace и хранилища данных в отдельных точках монтирования, что позволяет изменять размер хранилища данных независимо.
* Не хранить данные Dynatrace в корневом томе, чтобы избежать дополнительных сложностей при изменении размера диска позже, если это потребуется.
* Монтирование различных типов хранилищ данных на отдельных дисковых томах для максимальной гибкости и производительности.
* Создание разделов диска с изменяемым размером (например, с помощью диспетчера логических томов [LVM]).

==== Пути к каталогам по умолчанию и необходимое свободное место на диске для установки и обновления ====
Пути к каталогам, включенные в следующую таблицу, являются путями по умолчанию. Фактические пути могут отличаться, если вы установили в собственный каталог.
----<big>'''Пользовательские каталоги'''</big>

Если вы настроили места хранения, SERVER_DATASTORE_PATH, CASSANDRA_DATASTORE_PATH, ELASTICSEARCH_DATASTORE_PATH следует поместить в отдельные каталоги, и они не должны быть подкаталогами другого каталога.
----
{| class="wikitable"
!Символ каталога
!Путь к каталогу
!Описание
!Необходимое

свободное

место на диске

для установки
!Требуемое

свободное

место на диске

для обновления
|-
|PRODUCT_PATH
|/opt/dynatrace-managed
|Главный каталог для управляемых двоичных файлов Dynatrace
|7 GB
|5 GB
|-
|DATASTORE_PATH
|/var/opt/dynatrace-managed
|Главный каталог для данных Dynatrace Managed
|24 GB
|3 GB
|-
|LOG_PATH
|DATASTORE_PATH/log
|Журналы всех управляемых компонентов, сервисов и инструментов Dynatrace
|2 GB
|1 GB
|-
|CASSANDRA_DATASTORE_PATH
|DATASTORE_PATH/cassandra
|Репозиторий метрик
|25 GB
|1 GB
|-
|ELASTICSEARCH_DATASTORE_PATH
|DATASTORE_PATH/elasticsearch
|Магазин Elasticsearch
|3 GB
|1 GB
|-
|SERVER_DATASTORE_PATH
|DATASTORE_PATH/server/tenantData
|Магазин транзакций
|14 GB
|1 GB
|-
|SERVER_REPLAY_DATASTORE_PATH
|DATASTORE_PATH/server/replayData
|Магазин повторов сессий
|14 GB
|1 GB
|-
|AGENT_BUILD_UNITS_PATH
|DATASTORE_PATH/agents
|Установочные пакеты OneAgent и ActiveGate (если они загружены сервером Dynatrace или установлены из отдельных пакетов)
|20 GB
|1 GB
|-
|SERVER_BUILD_UNITS_PATH
|DATASTORE_PATH/installer
|Управляемый установщик Dynatrace для добавления узлов в кластер, подготовленный во время установки / обновления
|2 GB
|1 GB
|-
|SELFMON_AGENT_INSTALL_PATH

Также см. Дисковое пространство для OneAgent.
|/opt/dynatrace
|Главный каталог для самоконтроля двоичных файлов OneAgent.
|4.8 GB
|1.4 GB
|}
----<big>''Отказ от OneAgent''</big>

Самоконтроль OneAgent включен по умолчанию. Доступен параметр отказа от установки:

<code>--install-agent <on|off></code>
----

=== Поддерживаемые файловые системы ===
Dynatrace Managed работает со всеми распространенными файловыми системами. Мы рекомендуем вам выбрать быстрое локальное хранилище, подходящее для рабочих нагрузок базы данных. Удаленные тома с высокой задержкой, такие как NFS или CIFS, не рекомендуются. Хотя файловых систем NFS достаточно для резервного копирования, мы не рекомендуем их в качестве основного хранилища.
----<big>''Amazon Elastic File System''</big>

Мы не поддерживаем и не рекомендуем Amazon Elastic File System (EFS) в качестве основного хранилища для Elasticsearch. Такие файловые системы не обеспечивают поведение, требуемое Elasticsearch, и это может привести к повреждению индекса.
----

== Рекомендации Log Monitoring v2 ==
Для Log Monitoring v2 мы рекомендуем следующее:

* Для более надежной конфигурации лучше добавить больше узлов кластера, чем увеличивать оборудование на каждом узле.
* Распределите дополнительное хранилище Elasticsearch поровну между узлами кластера.
* Добавьте ЦП и ОЗУ к существующим узлам кластера, чтобы узлы оставались одинакового размера.
* Для каждых ста миллионов (100000000) событий журнала в день (70000 событий в минуту в среднем и 140000 событий в минуту во время пиков) в вашем кластере добавьте дополнительные ресурсы, распределенные по всем узлам кластера:
** 5 ядер ЦП
** Диск емкостью 3,3 ТБ (содержит 2 реплики данных для обеспечения высокой доступности)
** 6,5 ГБ RAM

Например, для обработки трехсот миллионов (300 000 000) событий журнала в день вам потребуются дополнительные 15 ЦП, 9,9 ТБ диска и 19,5 ГБ ОЗУ. В существующем кластере из трех узлов среднего размера вы можете выполнить одно из следующих действий:

*  Добавить два дополнительных узла среднего размера, чтобы сформировать кластер из пяти узлов. Кроме того, увеличьте хранилище Elasticsearh на каждом узле на 2 ТБ (в этом случае каждый узел хранит 40% дважды реплицированных данных).

* Добавьте 3,3 ТБ дискового хранилища (каждый узел хранит 67% дважды реплицированных данных), 8 ЦП и 16 ГБ ОЗУ на каждый узел.

Следующие рекомендации основаны на приблизительном количестве событий журнала в день:
{| class="wikitable"
!Журнал событий в день
!Дополнительные процессоры
!Дополнительное дисковое пространство
!Дополнительная оперативная память
|-
|Сто миллионов (100 000 000)
|5
|3.3 TB
|6.5 GB
|-
|Триста миллионов (300 000 000)
|15
|9.9 TB
|19.5 GB
|-
|Пятьсот миллионов (500 000 000)
|25
|16.5 TB
|32 GB
|}
В случае более крупных или насыщенных событий или если вы превышаете один миллиард (1 000 000 000) событий журнала в день, обратитесь в службу поддержки за советом по определению размера.

'''Примечание:'''

* Эти рекомендации дополняют любые требования от других источников трафика.
* События журнала хранятся в хранилище Elasticsearch.
* События журнала хранятся с коэффициентом репликации 2.
* Имейте в виду, что время хранения событий журнала составляет 35 дней.

== Многоузловые установки ==
Мы рекомендуем установки с несколькими узлами для аварийного переключения и резервирования данных. Рекомендуемая конфигурация - трехузловой кластер достаточного размера. Для установок Dynatrace Managed с более чем одним узлом все узлы должны:

* Иметь такую же конфигурацию оборудования
* Быть синхронизированным с NTP
* Быть в том же часовом поясе
* Уметь общаться через частную сеть на нескольких портах
* Задержка между узлами должна быть около 10 мс или меньше.
* Системные пользователи, созданные для Dynatrace Managed, должны иметь одинаковые идентификаторы UID: GID на всех узлах.

----<big>''Избегайте проблем с синхронизацией разделенного мозга''</big>

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

← Предыдущая		Версия 10:14, 7 марта 2022
Строка 1:		Строка 1:
	В этом разделе описывается оборудование для установки Ключ-АСТРОМ Managed. Другие требования Ключ-АСТРОМ Managed см. в разделах [[Требования Managed к системе]] и Рекомендации по оборудованию для облачных развертываний Managed.		В этом разделе описывается оборудование для установки Ключ-АСТРОМ Managed. Другие требования Ключ-АСТРОМ Managed см. в разделах [[Требования Managed к системе]] и Рекомендации по оборудованию для облачных развертываний Managed.
	----<big>''Соображения по размеру''</big>		----<blockquote><big>''Соображения по размеру''</big>

	Калибровка обычно состоит из следующих элементов:		Калибровка обычно состоит из следующих элементов:
Строка 9:		Строка 9:
	* Рекомендации по Log Monitoring 2.0		* Рекомендации по Log Monitoring 2.0

	Обязательно изучите каждый элемент, прежде чем продолжить.		Обязательно изучите каждый элемент, прежде чем продолжить.</blockquote>
	----		----

Строка 277:		Строка 277:
	\|1.4 ГБ		\|1.4 ГБ
	\|}		\|}
	----<big>''ЕдиныйАгент opt-out''</big>		----<blockquote><big>''ЕдиныйАгент opt-out''</big>

	Самоконтроль ЕдиногоАгента включен по умолчанию. Доступен установочный параметр opt-out:		Самоконтроль ЕдиногоАгента включен по умолчанию. Доступен установочный параметр opt-out:

	<code>--install-agent <on\|off></code>		<code>--install-agent <on\|off></code></blockquote>
	----		----

	=== Поддерживаемые файловые системы ===		=== Поддерживаемые файловые системы ===
	Ключ-АСТРОМ Managed работает со всеми распространенными файловыми системами. Мы рекомендуем вам выбрать быстрое локальное хранилище, подходящее для рабочих нагрузок базы данных. Удаленные тома с высокой задержкой, такие как NFS или CIFS, не рекомендуются. Хотя файловых систем NFS достаточно для резервного копирования, мы не рекомендуем их в качестве основного хранилища.		Ключ-АСТРОМ Managed работает со всеми распространенными файловыми системами. Мы рекомендуем вам выбрать быстрое локальное хранилище, подходящее для рабочих нагрузок базы данных. Удаленные тома с высокой задержкой, такие как NFS или CIFS, не рекомендуются. Хотя файловых систем NFS достаточно для резервного копирования, мы не рекомендуем их в качестве основного хранилища.
	----<big>''Amazon Elastic File System''</big>		----<blockquote><big>''Amazon Elastic File System''</big>

	Мы не поддерживаем и не рекомендуем Amazon Elastic File System (EFS) в качестве основного хранилища для Elasticsearch. Такие файловые системы не обеспечивают поведение, требуемое Elasticsearch, и это может привести к повреждению индексов.		Мы не поддерживаем и не рекомендуем Amazon Elastic File System (EFS) в качестве основного хранилища для Elasticsearch. Такие файловые системы не обеспечивают поведение, требуемое Elasticsearch, и это может привести к повреждению индексов.</blockquote>
	----		----

Строка 329:		Строка 329:
	* Системные пользователи, созданные для Ключ-АСТРОМ Managed, должны иметь одинаковые идентификаторы UID:GID на всех узлах.		* Системные пользователи, созданные для Ключ-АСТРОМ Managed, должны иметь одинаковые идентификаторы UID:GID на всех узлах.

	----<big>''Избегайте проблем с синхронизацией split-brain''</big>		----<blockquote><big>''Избегайте проблем с синхронизацией split-brain''</big>

	Хотя кластеры из двух узлов технически возможны, мы не рекомендуем этого делать. Наши системы хранения основаны на консенсусе и требуют большинства для согласованности данных. Вот почему двухузловой кластер уязвим для проблемы split-brain и должен рассматриваться как временное состояние при переходе на 3 или более узлов. Запуск двух узлов может привести к несогласованности доступности или данных из двух отдельных наборов данных (кластеры с одним узлом), которые перекрываются и не обмениваются данными и не синхронизируют свои данные друг с другом.		Хотя кластеры из двух узлов технически возможны, мы не рекомендуем этого делать. Наши системы хранения основаны на консенсусе и требуют большинства для согласованности данных. Вот почему двухузловой кластер уязвим для проблемы split-brain и должен рассматриваться как временное состояние при переходе на 3 или более узлов. Запуск двух узлов может привести к несогласованности доступности или данных из двух отдельных наборов данных (кластеры с одним узлом), которые перекрываются и не обмениваются данными и не синхронизируют свои данные друг с другом.</blockquote>
	----		----