Оценивание затрат на мониторинг Виртуального рабочего стола Azure
Виртуальный рабочий стол Azure использует службу журналов Azure Monitor для сбора, индексации и хранения данных, созданных вашей средой. В связи с этим модель ценообразования Azure Monitor основана на объеме данных, которые передаются и обрабатываются (или принимаются) рабочей областью Log Analytics в гигабайтах в день. Затраты на рабочую область Log Analytics зависят не только от объема получаемых данных, но и от того, какой план оплаты Azure был выбран и как долго вы решили хранить данные, создаваемые средой.
В этой статье рассматриваются следующие вопросы, которые помогут понять, как работает ценообразование в Azure Monitor.
- Как оценить затраты на прием и хранение данных перед включением этой функции.
- Как измерять и контролировать прием и хранение данных, чтобы снизить затраты при использовании этой функции.
Примечание.
Все размеры и цены, перечисленные в этой статье, являются просто примерами для демонстрации работы оценки. Чтобы получить более точную оценку на основе модели ценообразования Azure Monitor в Log Analytics и региона Azure, перейдите на страницу цен на Azure Monitor.
Оценка затрат на прием и хранение данных
Рекомендуется использовать предопределенный набор данных, записанных в виде журналов в рабочей области Log Analytics. В следующем примере оценки будут рассмотрены оплачиваемые данные в конфигурации по умолчанию.
Стандартные наборы данных для Аналитики виртуальных рабочих столов Azure включают:
- счетчики производительности из узлов сеансов;
- журналы событий Windows из узлов сеансов;
- диагностику Виртуальных рабочих столов Azure из инфраструктуры службы.
Стоимость приема и хранения данных зависит от размера, работоспособности и использования вашей среды. Пример оценки, который будет использоваться в этой статье для вычисления диапазонов затрат, можно рассчитать на основе рекомендаций по выбору размера виртуальных машин, работающих с низкой степенью энергопотребления.
В нашем примере используется виртуальная машина с низкой интенсивностью использования, которая включает в себя следующие компоненты:
- 4 виртуальных ЦП, 1 диск;
- 16 сеансов в день;
- средняя длительность сеанса: 2 часа (120 минут);
- 100 процессов на сеанс.
В нашем примере используется виртуальная машина, которая включает в себя следующие компоненты:
- 6 виртуальных ЦП, 1 диск;
- 6 сеансов в день;
- средняя длительность сеанса: 4 часа (240 минут);
- 200 процессов на сеанс.
Оценка приема счетчика производительности
Счетчики производительности показывают, как используются системные ресурсы. Прием данных счетчика производительности зависит от размера и использования среды. В большинстве случаев счетчики производительности должны составлять от 80 до 99 % от приема данных для Аналитики виртуальных рабочих столов Azure.
Прежде чем начать оценку, важно понимать, что каждый счетчик производительности отправляет данные с определенной периодичностью. Установим частоту выборки по умолчанию (в минуту) (можно также изменить эту частоту в параметрах), но эта частота будет применяться с различными коэффициентами умножения в зависимости от счетчика. На скорость влияют следующие факторы:
Для каждого фактора виртуальной машины каждый счетчик отправляет данные на виртуальную машину в вашей среде с частотой выборки по умолчанию в минуту во время работы виртуальной машины. Вы можете оценить количество записей, отправляемых этими счетчиками в день, умножив частоту выборки по умолчанию в минуту на количество виртуальных машин в вашей среде, а затем умножив это число на среднее время работы виртуальной машины в день.
Подведение итогов.
Частота выборки по умолчанию в минуту × число ядер ЦП в номере SKU виртуальной машины × число виртуальных машин × среднее время работы виртуальной машины в день = число записей, отправляемых в день.
Для каждого фактора ЦП каждый счетчик отправляет частоту выборки по умолчанию в минуту для каждого виртуального ЦП на каждой виртуальной машине в среде во время работы виртуальной машины. Вы можете оценить количество записей, которые будут отправлены счетчиками за день, умножив частоту выборки по умолчанию в минуту на количество ядер ЦП в номере SKU виртуальной машины, а затем умножив это число на количество минут, в течение которых работает виртуальная машина, и на число виртуальных машин в вашей среде.
Подведение итогов.
Частота выборки по умолчанию в минуту × число ядер ЦП в номере SKU виртуальной машины × число минут, в течение которых работает виртуальная машина × число виртуальных машин = количество записей, отправляемых в день.
Для фактора каждого диска каждый счетчик отправляет данные при частоте выборки по умолчанию для каждого диска в каждой виртуальной машине в вашей среде. Число записей, отправляемых этими счетчиками в день, равно частоте выборки по умолчанию в минуту, умноженной на число дисков в номере SKU виртуальной машины, умноженное на 60 минут в час, а затем умноженное на среднее количество рабочих часов виртуальной машины.
Подведение итогов.
Частота выборки по умолчанию в минуту × число дисков в номере SKU виртуальной машины × 60 минут в час × число виртуальных машин × среднее время работы виртуальной машины в день = количество записей, отправляемых в день.
Для фактора каждого сеанса каждый счетчик отправляет данные по частоте выборки по умолчанию для каждого сеанса в среде во время подключения сеанса. Вы можете оценить количество записей, которые эти счетчики будут отправлять в день, умножив частоту выборки по умолчанию в минуту на среднее количество сеансов в день и среднюю продолжительность сеанса.
Подведение итогов.
Частота выборки по умолчанию в минуту × количество сеансов в день x средняя длительность сеанса = количество записей, отправляемых в день.
Для фактора каждого процесса каждый счетчик отправляет данные с частотой по умолчанию для каждого процесса в каждом сеансе в вашем окружении. Вы можете оценить количество записей, которые будут отправлены этими счетчиками за день, умножив частоту выборки по умолчанию в минуту на среднее количество сеансов в день, а затем умножив их на среднюю продолжительность сеанса и среднее число процессов в сеансе.
Подведение итогов.
Частота выборки по умолчанию в минуту × количество сеансов в день x средняя длительность сеанса × среднее число процессов в сеансе = число записей, отправляемых в день.
В следующей таблице перечислены 20 счетчиков производительности Azure Virtual Desktop Insights, собираемых ими по умолчанию.
| Имя счетчика | Частота выборки по умолчанию | Фактор частоты |
|---|---|---|
| Логический диск (C:)\% свободного пространства | 60 секунд | на диск |
| Логический диск (C:)\Средняя длина очереди диска | 30 секунд | на диск |
| Логический диск (C:)\среднее время обращения к диску (с) | 60 секунд | на диск |
| Логический диск (C:)\Текущая длина очереди диска | 30 секунд | на диск |
| Память(*)\Доступный объем в МБ | 30 секунд | на виртуальную машину |
| Память (*)\ошибок страницы/с | 30 секунд | на виртуальную машину |
| Память (*)\Страниц/с | 30 секунд | на виртуальную машину |
| Память (*)\Использование выделенной памяти (в байтах) | 30 секунд | на виртуальную машину |
| PhysicalDisk (*)\средняя длина очереди диска | 30 секунд | на диск |
| PhysicalDisk (*)\среднее время чтения с диска (с) | 30 секунд | на диск |
| PhysicalDisk (*)\среднее время обращения к диску (с) | 30 секунд | на диск |
| PhysicalDisk (*)\среднее время записи на диск (с) | 30 секунд | на диск |
| Сведения о процессоре (_Total)\% загруженности процессора | 30 секунд | На ядро или ЦП |
| Службы терминалов (*)\Активные сеансы | 60 секунд | на виртуальную машину |
| Службы терминалов (*)\Неактивные сеансы | 60 секунд | на виртуальную машину |
| Службы терминалов (*)\Всего сеансов | 60 секунд | на виртуальную машину |
| Задержка данных, введенных пользователем за процесс (*)\максимальная задержка входных данных | 30 секунд | На процесс |
| Задержка данных, введенных пользователем за сеанс (*)\максимальная задержка входных данных | 30 секунд | На сеанс |
| Сеть RemoteFX (*)\RTT текущего TCP-подключения | 30 секунд | на виртуальную машину |
| Сеть RemoteFX (*)\пропускная способность текущего UDP-подключения | 30 секунд | на виртуальную машину |
Если мы предполагаем, что размер каждой записи составляет 200 байт, пример виртуальной машины, на которой используется небольшая рабочая нагрузка при частоте выборки по умолчанию, будет отправлять примерно 90 МБ данных счетчика производительности в день для каждой виртуальной машины. В то же время, пример виртуальной машины, на которой выполняется существенная рабочая нагрузка, будет отправлять примерно 130 МБ данных счетчика производительности в день на каждую виртуальную машину. Однако размер записи и использование среды могут различаться, поэтому количество мегабайт в день, используемых при развертывании, может отличаться.
Дополнительные сведения о счетчиках производительности входных данных см. в статье о счетчиках производительности задержки входных данных.
Оценка приема журнала событий Windows
Журналы событий Windows — это источники данных, собранные агентом Azure Monitor или агентом Log Analytics на виртуальных машинах Windows. События можно собирать из стандартных журналов, таких как "Система" и "Приложение", а также из пользовательских журналов, созданных приложениями, которые необходимо отслеживать.
Это события Windows по умолчанию для Аналитики виртуальных рабочих столов Azure:
- Приложение
- Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin
- Microsoft-Windows-TerminalServices-LocalSessionManager/Operational
- Системные
- Microsoft-FSLogix-Apps/Operational
- Microsoft-FSLogix-Apps/Admin
События Windows отправляют события всякий раз, когда среда соответствует условиям события. Компьютеры в работоспособном состоянии будут передавать меньше событий, чем компьютеры в неработоспособном. Так как число событий является непредсказуемым, мы используем диапазон от 1000 до 10 000 событий на каждую виртуальную машину в день на основе примеров из работоспособной среды для этой оценки. Например, если мы оценим размер каждой записи о событии в этом примере в 1500 байтов, это будет примерно от 2 до 15 мегабайт данных о событиях в день для указанной среды.
Дополнительные сведения о настройке сбора данных журнала событий Windows с помощью агента Azure Monitor см. в статье о сборе событий и счетчиков производительности с виртуальных машин с помощью агента Azure Monitor.
Дополнительные сведения о журналах событий Windows см. в разделе о свойствах записей "События Windows".
Оценка приема диагностических сведений
С помощью службы диагностики можно создавать журналы действий как для пользователей, так и для административных действий.
Ниже приведены имена журналов действий, отслеживающих счетчики диагностики:
- WVDCheckpoints
- WVDConnections
- WVDErrors
- WVDFeeds
- WVDManagement
- WVDAgentHealthStatus
Служба отправляет диагностические сведения каждый раз, когда среда соответствует условиям, необходимым для создания записи. Так как количество диагностических записей непредсказуемо, мы используем диапазон от 500 до 1000 событий на виртуальную машину в день на основе примеров из работоспособной среды для этой оценки.
Например, если мы оценим размер каждой диагностической записи в этом примере в 200 байтов, то общий объем полученных данных будет менее 1 МБ на виртуальную машину в день.
Дополнительные сведения о категориях журналов действий см. в статье Использование Log Analytics для функции диагностики.
Измерение данных счетчиков производительности и управление ими
Истинные затраты на мониторинг будут зависеть от размера, использования и работоспособности вашей среды. Чтобы понять, как измерять прием данных в рабочей области Log Analytics, см. статью Анализ использования рабочей области Log Analytics.
Счетчики производительности, используемые узлами сеансов, являются одним из крупнейших источников приема данных для Службы "Аналитика виртуальных рабочих столов Azure". Этот запрос будет отображать все счетчики производительности, которые вы включили в среде, а не только значения по умолчанию для Аналитики виртуальных рабочих столов Azure. Эти сведения помогут вам понять, какие области предназначены для снижения затрат.
Выполните следующий пользовательский шаблон запроса для рабочей области Log Analytics, чтобы отслеживать частоту и прием мегабайтов на счетчик производительности за последний день:
Примечание.
Обязательно замените значения заполнителей шаблона значениями, используемыми в вашей среде, в противном случае запрос не будет работать.
let WVDHosts = dynamic(['Host1.MyCompany.com', 'Host2.MyCompany.com']);
Perf
| where TimeGenerated > ago(1d)
| where Computer in (WVDHosts)
| extend PerfCounter = strcat(ObjectName, ":", CounterName)
| summarize Records = count(TimeGenerated), InstanceNames = dcount(InstanceName), Bytes=sum(_BilledSize) by PerfCounter
| extend Billed_MBytes = Bytes / (1024 * 1024), BytesPerRecord = Bytes / Records
| sort by Records desc
Оценка общих затрат
Наконец, давайте выполним оценку общей стоимости. В этом примере предположим, что мы получаем следующие результаты, основанные на примерах значений в предыдущих разделах:
| Источник данных | Оценка размера в день (в мегабайтах) |
|---|---|
| Счетчики производительности | 90–130 |
| События | 2–15 |
| Диагностика Виртуальных рабочих столов Azure | < 1 |
В этом примере общий прием данных для Аналитики виртуальных рабочих столов Azure составляет от 92 до 145 мегабайт на виртуальную машину в день. Иными словами, каждый 31 день каждая виртуальная машина принимает примерно 3–5 гигабайт данных.
Используя модель оплаты по мере использования по умолчанию для ценообразования Log Analytics, можно оценить ежемесячную стоимость сбора и хранения данных Azure Monitor. В зависимости от приема данных вы также можете рассмотреть модель резервирования емкости для ценообразования Log Analytics.
Управление приемом данных для снижения затрат
В этом разделе объясняется, как измерять прием данных и управлять им для снижения затрат.
Дополнительные сведения об управлении правами и разрешениями для книг см. в статье Управление доступом.
Примечание.
Удаление точек данных повлияет на соответствующие визуальные элементы в Службе "Аналитика виртуальных рабочих столов Azure".
Параметры Log Analytics
Ниже приведены некоторые рекомендации по оптимизации параметров Log Analytics для управления приемом данных.
- Используйте назначенную рабочую область Log Analytics для ресурсов Виртуальных рабочих столов Azure, чтобы гарантировать, что Log Analytics собирает только счетчики производительности и события для виртуальных машин в развертывании Виртуальных рабочих столов Azure.
- Настройте параметры хранилища Log Analytics для управления затратами. Можно уменьшить срок хранения, оценить, является ли фиксированная ценовая категория более экономичной, или задать границы объема данных, которые можно принять, чтобы ограничить влияние неработоспособного развертывания. Дополнительные сведения см. в статье Сведения о ценах на журналы Azure Monitor.
Удаление лишних данных
Наша конфигурация по умолчанию — это единственный набор данных, которые мы рекомендуем использовать для Аналитики виртуальных рабочих столов Azure. Вы всегда можете добавить дополнительные точки данных и просмотреть их в окне диагностики узла или браузере узла. Можно также создать пользовательские диаграммы для них, однако добавленные данные увеличивают затраты на Log Analytics. Их можно удалить для экономии затрат.
Измерение данных счетчиков производительности и управление ими
Истинные затраты на мониторинг будут зависеть от размера, использования и работоспособности вашей среды. Чтобы понять, как измерять прием данных в рабочей области Log Analytics, см. статью Анализ использования рабочей области Log Analytics.
Счетчики производительности, используемые узлами сеансов, вероятно, будут самым большим источником приема данных для Службы "Аналитика виртуальных рабочих столов Azure". Следующий пользовательский шаблон запроса для рабочей области Log Analytics может отслеживать частоту и количество мегабайт, полученных для счетчика производительности за последний день:
let WVDHosts = dynamic(['Host1.MyCompany.com', 'Host2.MyCompany.com']);
Perf
| where TimeGenerated > ago(1d)
| where Computer in (WVDHosts)
| extend PerfCounter = strcat(ObjectName, ":", CounterName)
| summarize Records = count(TimeGenerated), InstanceNames = dcount(InstanceName), Bytes=sum(_BilledSize) by PerfCounter
| extend Billed_MBytes = Bytes / (1024 * 1024), BytesPerRecord = Bytes / Records
| sort by Records desc
Примечание.
Обязательно замените значения заполнителей шаблона значениями, используемыми в вашей среде, в противном случае запрос не будет работать.
Этот запрос будет отображать все счетчики производительности, которые вы включили в среде, а не только значения по умолчанию для Аналитики виртуальных рабочих столов Azure. Эти сведения помогут понять, в каких областях можно снизить затраты, например уменьшить частоту счетчика или полностью удалить его.
Уменьшить затраты можно также, удалив счетчики производительности. Чтобы узнать, как удалить счетчики производительности или уменьшить частоту существующих счетчиков, см. раздел Настройка счетчиков производительности.
Управление журналами событий Windows
События Windows вряд ли вызовут всплеск приема данных, когда все узлы работоспособны. Неработоспособный узел может увеличить количество событий, отправляемых в журнал, но эта информация может иметь решающее значение для устранения проблем с узлом. Такие узлы рекомендуется сохранить. Дополнительные сведения об управлении журналами событий Windows см. в разделе Настройка журналов событий Windows.
Управление диагностикой
Диагностика Виртуальных рабочих столов Azure должна составлять менее 1 % ваших затрат на хранение данных, поэтому мы не рекомендуем их удалять. Дополнительные сведения см. в статье Использование Log Analytics для функции диагностики.
Следующие шаги
Дополнительные сведения об Azure Virtual Desktop Insights см. в следующих статьях:
- Используйте Аналитику виртуальных рабочих столов Azure для мониторинга развертывания.
- Дополнительные сведения о терминах и концепциях см. в глоссарии.
- Если у вас возникла проблема, ознакомьтесь с нашим руководством по устранению неполадок.
- Ознакомьтесь с затратами и использованием Azure Monitor, чтобы узнать больше об управлении затратами на мониторинг.