Требования Managed к оборудованию: различия между версиями

Материал из Dynatrace
(Новая страница: «В этом разделе объясняется оборудование для установки Dynatrace Managed. Другие требования Dynatrac...»)
 
 
(не показано 6 промежуточных версий 2 участников)
Строка 1: Строка 1:
В этом разделе объясняется оборудование для установки Dynatrace Managed. Другие требования Dynatrace Managed см. в разделах Требования к управляемой системе и Рекомендации по управляемому оборудованию для облачных развертываний.
В этом разделе описывается оборудование для установки Dynatrace Managed. Другие требования Dynatrace Managed см. в разделах [[Требования Managed к системе]] и Рекомендации по оборудованию для облачных развертываний Managed.
----<big>''Соображения по размеру''</big>
----<blockquote><big>''Соображения по размеру''</big>


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


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


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


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


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


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


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


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


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


Требование 4 ТБ для узла XLarge следует рассматривать как максимально допустимый размер. Если вам нужна дополнительная емкость, подумайте о добавлении еще одного узла. Планируйте свое хранилище долгосрочных метрик так, чтобы данные занимали не более 50% доступного дискового пространства. Таким образом, 4 ТБ пространства будут обрабатывать 2 ТБ данных вашего долгосрочного хранилища метрик. Хотя возможны хранилища размером более 4 ТБ, они могут затруднить обслуживание базы данных.
=== Dynatrace Managed ===
 
=== Ключ-АСТРОМ Managed ===
{| class="wikitable"
{| class="wikitable"
!Тип узла
!Тип узла
!Макс хостов
!Макс. хостов


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


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


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


(на узел)
(на узел)
!Мин узел
!'''Минимальные спецификации узла'''
 
технические характеристики
!Диск IOPS
!Диск IOPS


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


(Видимость кода 10 дней)
(видимость кода 10 дней)
!Долгосрочное
!'''Хранилище долгосрочных'''
 
'''метрик'''
Магазин метрик


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


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


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


=== Ключ-АСТРОМ Managed Premium High Availability ===
=== Dynatrace Managed Премиум высокой доступности ===
{| class="wikitable"
{| class="wikitable"
!Тип узла
!Тип узла
Строка 161: Строка 158:
|600
|600
|25000
|25000
|32 vCPUs,
|32 виртуальных ЦП,
256 GB RAM
256 ГБ ОЗУ
|7500
|7500
|1 TB
|1 ТБ
|2 TB
|2 ТБ
|1.5 TB
|1.5 ТБ
|-
|-
|XБольшой<sup>1</sup>
|XБольшой<sup>1</sup>
|1250
|1250
|50000
|50000
|64 vCPUs,
|64 виртуальных ЦП,
512 GB RAM
512 ГБ ОЗУ
|10000
|10000
|2 TB
|2 ТБ
|4 TB
|4 ТБ
|3 TB
|3 ТБ
|}
|}
<sup>1</sup> Хотя Dynatrace Managed устойчиво работает на инстансах с 1 ТБ + ОЗУ / 128 ядрами (2XLarge) и позволяет отслеживать больше объектов, это не оптимальный способ использования оборудования. Вместо этого мы рекомендуем использовать экземпляры меньшего размера (Large или XLarge).
<sup>1</sup> Хотя Dynatrace Managed устойчиво работает на экземплярах с 1+ ТБ ОЗУ/128 ядрами (2XБольшой) и позволяет отслеживать больше объектов, это не оптимальный способ использования оборудования. Вместо этого мы рекомендуем использовать экземпляры меньшего размера (Большой или XБольшой).


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


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


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


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


Если вы настроили места хранения, SERVER_DATASTORE_PATH, CASSANDRA_DATASTORE_PATH, ELASTICSEARCH_DATASTORE_PATH следует поместить в отдельные каталоги, и они не должны быть подкаталогами другого каталога.
Если вы настроили места хранения, <code>SERVER_DATASTORE_PATH</code>, <code>CASSANDRA_DATASTORE_PATH</code>, <code>ELASTICSEARCH_DATASTORE_PATH</code> следует поместить в отдельные каталоги, и они не должны быть подкаталогами другого каталога.
----
----
{| class="wikitable"
{| class="wikitable"
Строка 210: Строка 207:


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


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


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


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


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


=== Поддерживаемые файловые системы ===
=== Поддерживаемые файловые системы ===
Dynatrace Managed работает со всеми распространенными файловыми системами. Мы рекомендуем вам выбрать быстрое локальное хранилище, подходящее для рабочих нагрузок базы данных. Удаленные тома с высокой задержкой, такие как NFS или CIFS, не рекомендуются. Хотя файловых систем NFS достаточно для резервного копирования, мы не рекомендуем их в качестве основного хранилища.
Dynatrace 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>
----
----


== Рекомендации Log Monitoring v2 ==
== Рекомендации по Log Monitoring v2 ==
Для Log Monitoring v2 мы рекомендуем следующее:
Требования для Log Monitoring v2:
 
* Все узлы кластера должны иметь не менее 64 ГБ ОЗУ общей памяти хоста.
 
Дополнительные рекомендации по установке:


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


Например, для обработки трехсот миллионов (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 ТБ дискового хранилища (включая репликацию), 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) событий журнала в день, обратитесь в службу поддержки за советом по определению размера.


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


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


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


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

Текущая версия на 09:41, 20 января 2023

В этом разделе описывается оборудование для установки Dynatrace Managed. Другие требования Dynatrace Managed см. в разделах Требования Managed к системе и Рекомендации по оборудованию для облачных развертываний Managed.


Соображения по размеру

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

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

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


Генеральная планировка

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

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

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

Требования к оборудованию

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

  • Минимальные спецификации узла
    • ЦП и ОЗУ должны быть доступны исключительно для Dynatrace. Режим энергосбережения для ЦП должен быть отключен. Процессоры должны работать с тактовой частотой не менее 2 ГГц, а хосту должно быть назначено не менее 32 ГБ ОЗУ.
  • Хранилище транзакций
    • Данные транзакций распределяются по всем узлам и не хранятся избыточно. В кластерах с несколькими узлами хранилище данных транзакций делится на количество узлов.
  • Хранилище долгосрочных метрик
    • Для многоузловых установок сохраняются три копии хранилища метрик. Для четырех или более узлов требования к хранилищу на каждый узел снижаются.
    • Требование 4 ТБ для узла XБольшой следует рассматривать как максимально допустимый размер. Если вам нужна дополнительная емкость, подумайте о добавлении ещё одного узла. Планируйте свое хранилище долгосрочных метрик так, чтобы данные занимали не более 50% доступного дискового пространства. Таким образом, 4 ТБ пространства будут обрабатывать 2 ТБ данных вашего долгосрочного хранилища метрик. Хотя возможны хранилища размером более 4 ТБ, они могут затруднить обслуживание базы данных.

Dynatrace Managed

Тип узла Макс. хостов

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

(на узел)

Пиковое количество пользовательских

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

(на узел)

Минимальные спецификации узла Диск IOPS

(на узел)

Хранилище

транзакций

(видимость кода 10 дней)

Хранилище долгосрочных

метрик

(на узел)

Elasticsearch

(на узел)

(Срок хранения 35 дней)

Микро 50 1000 4 виртуальных ЦП,

32 ГБ ОЗУ

500 50 ГБ 100 ГБ 50 ГБ
Небольшой 300 10000 8 виртуальных ЦП,

64 ГБ ОЗУ

3000 300 ГБ 500 ГБ 500 ГБ
Средний 600 25000 16 виртуальных ЦП,

128 ГБ ОЗУ

5000 600 ГБ 1 ТБ 1.5 ТБ
Большой 1250 50000 32 виртуальных ЦП,

256 ГБ ОЗУ

7500 1 ТБ 2 ТБ 1.5 ТБ
XБольшой1 2500 100000 64 виртуальных ЦП,

512 ГБ ОЗУ

10000 2 ТБ 4 ТБ 3 ТБ

1 Хотя Dynatrace Managed устойчиво работает на экземплярах с 1+ ТБ ОЗУ/128 ядрами (2XБольшой) и позволяет отслеживать больше объектов, это не оптимальный способ использования оборудования. Вместо этого мы рекомендуем использовать экземпляры меньшего размера (Большой или XБольшой).

Примеры

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

Dynatrace Managed Премиум высокой доступности

Тип узла Макс хостов

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

(на узел)

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

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

(на узел)

Мин узел

технические характеристики

Диск IOPS

(на узел)

Хранение транзакций

(Видимость кода 10 дней)

Долгосрочное

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

(на узел)

Elasticsearch

(на узел)

(Срок хранения 35 дней)

Большой 600 25000 32 виртуальных ЦП,

256 ГБ ОЗУ

7500 1 ТБ 2 ТБ 1.5 ТБ
XБольшой1 1250 50000 64 виртуальных ЦП,

512 ГБ ОЗУ

10000 2 ТБ 4 ТБ 3 ТБ

1 Хотя Dynatrace Managed устойчиво работает на экземплярах с 1+ ТБ ОЗУ/128 ядрами (2XБольшой) и позволяет отслеживать больше объектов, это не оптимальный способ использования оборудования. Вместо этого мы рекомендуем использовать экземпляры меньшего размера (Большой или XБольшой).

Пример

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

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

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

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

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

Пути к каталогам по умолчанию и необходимое свободное место на диске для установки и обновления

Пути к каталогам, включенные в следующую таблицу, являются путями по умолчанию. Фактические пути могут отличаться, если вы установили в собственный каталог.


Пользовательские каталоги

Если вы настроили места хранения, SERVER_DATASTORE_PATH, CASSANDRA_DATASTORE_PATH, ELASTICSEARCH_DATASTORE_PATH следует поместить в отдельные каталоги, и они не должны быть подкаталогами другого каталога.


Символ каталога Путь к каталогу Описание Необходимое

свободное

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

для установки

Необходимое

свободное

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

для обновления

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

Также см. Дисковое пространство для OneAgent

/opt/<namespace> Главный каталог для самоконтроля двоичных файлов OneAgent. 4.8 ГБ 1.4 ГБ

OneAgent opt-out

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

--install-agent <on|off>


Поддерживаемые файловые системы

Dynatrace Managed работает со всеми распространенными файловыми системами. Мы рекомендуем вам выбрать быстрое локальное хранилище, подходящее для рабочих нагрузок базы данных. Удаленные тома с высокой задержкой, такие как NFS или CIFS, не рекомендуются. Хотя файловых систем NFS достаточно для резервного копирования, мы не рекомендуем их в качестве основного хранилища.


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


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

Требования для Log Monitoring v2:

  • Все узлы кластера должны иметь не менее 64 ГБ ОЗУ общей памяти хоста.

Дополнительные рекомендации по установке:

  • Для более надежной конфигурации лучше добавить больше узлов кластера, чем увеличивать оборудование на каждом узле.
  • Распределите дополнительное хранилище Elasticsearch поровну между узлами кластера.
  • Добавьте ЦП и ОЗУ к существующим узлам кластера, чтобы узлы оставались одинакового размера.
  • Используйте REST API (Обновление событий журнала для каждого кластера для Log Monitoring), чтобы обновить предел загрузки кластера на основе доступных ресурсов для кластера.
  • Для каждых ста миллионов (100 000 000) событий журнала в день (70 000 событий в минуту в среднем и 140 000 событий в минуту во время пиков) в вашем кластере добавьте дополнительные ресурсы, распределенные по всем узлам кластера:
    • 5 ядер ЦП
    • Диск емкостью 3,3 ТБ (содержит реплики данных для высокой доступности)

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

  • [рекомендуется] Добавить два дополнительных узла среднего размера, чтобы сформировать кластер из пяти узлов. Кроме того, увеличьте хранилище Elasticsearh на каждом узле на 2 ТБ (в этом случае каждый узел хранит 40% дважды реплицированных данных).
  • Добавьте 3,3 ТБ дискового хранилища (включая репликацию), 8 ЦП и 16 ГБ ОЗУ на каждый узел.

Примечание:

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

Многоузловые установки

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

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

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