Ну как оптимизация. Креативные усилия по выравниванию кренящейся и шатающейся инфраструктуры, которую изо всех сил пытались удержать способом «ничего не трогайте, всё может поломаться». Опасная фраза, быстро превращающаяся в жизненную философию ИТ специалиста, остановившегося в развитии. Источник «ошаманивания» ИТ.
Полгода прошло с тех пор, как самый ответственный за виртуальную инфраструктуру человек уволился и оставил мне всё хозяйство и эксплуатационную документацию в виде списка служебных учёток. За это время был проведён ряд работ по укреплению фундамента, повышению надёжности и даже комфортности конструкции. Ключевыми моментами хочу поделиться.
Итак, дано:
Инфраструктура виртуализации VMware Enterprise Plus. Включает продуктив, тестовую зону и VDI. Последний реализован на базе продукта fujitsu Pano Logic, который уже 2 года как не обновляется и, судя по всему, не поддерживается.
Основной модернизируемый кластер — VDI, как самый объёмный критичный сервис и самый плотный по утилизации ресурсов. Реализован на базе полных клонов, ибо связанные клоны pano manager сам по себе не понимает, а покупать ещё и View бизнес не хочет.
В качестве СХД используется набор массивов EMC — несколько CX4-240 и пара VNX. А также есть такой изыск как IBM SVC. Используется для консолидации и виртуализации хранения (то есть lun монтируются со стораджей на SVC, там объединяются в пулы, а на этих пулах уже создаются новые LUN, отдаваемые серверам). Все хранилища подключены по FC SAN.
Так как документации не было, изучать, как что живёт и работает приходилось наживую. При этом некоторые безобидные, казалось бы, изменения, порой приводили к неожиданно неприятным последствиям, выявляя странные настройки и костыли.
Быстрая навигация:
1. Подсистема хранения
2. Сеть
3. Вычислительные ресурсы
Это направление я начал ещё до ухода коллеги, поскольку SAN и была основной моей зоной ответственности.
Первое, что меня удивило — использование большого количества датасторов маленького (1ТБ) размера. Зачем — никто объяснить не смог. Попытка консолидировать в датасторы побольше сразу выявила проблему — слишком большое количество scsi-блокировок, как следствие высокие latency и бут-штормы, как явление. Странным было то, что система хранения вела себя, как будто не поддерживала VAAI. Но в свойствах датасторов явно указано «Hardware Acceleration: Supported».
Понимание пришло, когда вводили новый хост в кластер. Коллега вспомнил, что перед эксплуатацией «надо ввести команду — отключить какую-то штуку, которая приводит к проблемам при работе с SVC». «Штукой» оказался параметр VMFS3.HardwareAcceleratedLocking, выставляемый в 0. Другими словами, отключалась, пожалуй, важнейшая функция VAAI — Atomic Test and Set (ATS) — позволяющая при изменении метаданных датастора (включение/выключение, миграция и растягивание тонких дисков ВМ) блокировать не весь датастор, а конкретные секторы на дисках.
Однако, эта настройка имела какие-то проблемы с SVC. По крайней мере, с той версией прошивки, что у нас была. Попытка обновления прошивок привела к смерти двух (из трёх обновлённых) нод, поддержка на данное оборудование закончилась, так что решили переносить датасторы напрямую на массивы EMC. Вообще так и осталось для меня непонятным — зачем надо было натягивать столь кривой слой виртуализации хранилищ поверх явно более продвинутого слоя сторадж пулов EMC.
Рекомендации: С точки зрения производительности, меньшее количество больших по размеру LUN выгоднее, чем большое количество маленьких — здесь и оверхед на обслуживание каждого LUN и распараллеливание запросов и ухудшение эффективности работы разных уровней кэша. (Рекомендация EMC по снижению нагрузки на SP: Reduce the number of LUNs by consolidating LUNs where possible. If a RAID group has multiple LUNs being used for the same host and application, then this can lead to linked contention, large seek distances and poor use of cache. Replacing these with fewer, larger LUNs will also reduce the amount of statistics which need to be monitored, therefore further reducing SP Utilization.)
При использовании систем виртуализации хранения, убедитесь, что они «интеллектуальнее» нижерасположенного уровня, или хотя бы не убивают функционал хранилищ. В нашем случае SVC явно была «глупее» массивов EMC, отказывалась видеть LUN'ы больше 2 ТБ и делала бессмысленным такие фичи, как автотиринг (и подозреваю, что Flash Cache).
Ну и конечно стоит убедиться, что оборудование хранения поддерживает VAAI, и, более того, что этот функционал не заблокирован на уровне инфраструктуры виртуализации.
Второй момент — странный разброс разных категорий данных по массивам. БД вперемешку с файл-серверами и VDI в хаотическом порядке были раскиданы по всем стораджам по принципу «где было место». Не говоря уж о том, что часть датасторов была подключена напрямую к EMC-массивам, а часть — через SVC.
После долгих миграций и перераспределений удалось распределить данные наиболее оптимальным образом — самые ресурсопотребляющие (продуктивные серверы и VDI) сложить на VNX'ы, а кларионы отдать под бэкапы и менее требовательные сервисы. В SVC остались только напрямую проброшенные в серверы LUN, все датасторы я из неё вынул. Число зон на коммутаторах сократилось с ~120 до ~75, с учётом того, что ранее встречались зоны типа «много таргетов — много инициаторов», а сейчас не более одного инициатора в зоне. Просто потому, что данные определённого типа, с которыми работали определённые серверы лежат теперь на одной СХД, а не на трёх разных.
В чём профит — лишние зоны создавали лишнюю нагрузку в SAN-сети, использование разнородной нагрузки (IO-интенсивной, типа БД и последовательной записи, типа бэкапов/файл-серверов) на одном массиве вредит производительности. Использование в одной зоне больше одного инициатора — bad practice.
# esxcli storage nmp device list на хостах показала, что
а) В большинстве своём для выбора путей до датасторов используется политика Round Robin,
б) Для части датасторов (первых шести) на первых двух хостах смена пути происходит через 3 IOPS
Path Selection Policy Device Config: {policy=iops,iops=3,
на остальных — дефолтное значение
Path Selection Policy Device Config: {policy=rr,iops=1000,
в) На последних пяти хостах кластера для части датасторов вообще использовался Fixed (всё общение с СХД идёт по одному пути, покуда он доступен).
Выбор Path Selection Policy определяется моделью и вендором СХД. В большинстве случаев, для конфигурация active-active используется round robin, ввиду какой-никакой, но балансировки нагрузки. По умолчанию смена пути происходит через 1000 iops. Однако в некоторых случаях это может привести к задержкам. Есть kb от VMware, где рекомендуется изменить это значение на 1. Есть тесты, показывающие, что производительность подсистемы хранения в этом случае реально выше.
Рекомендации: настраивайте multipathing в соответствии с рекомендациями вендоров для ваших конфигураций. И следите за тем, чтобы на всех хостах они были одинаковыми. Хорошо в этом помогают Host Profiles в VMware.
В целях настройки балансировки нагрузки, все коммутаторы блейд-корзины кластера VDI были объединены в стек, организован EtherChannel и load balancing в разделе Teaming and Failover был сконфигурирован как Route Based on IP Hash. Дело в том, что IP Hash работает только поверх EtherChannel и с EtherChannel совместим только IP Hash. Однако когда кластер вырос до второй блейд-корзины, коммутаторы которой не поддерживали EtherChannel, появилась проблема. Проблема проявлялась в виде жёсткого MAC-флаппинга на коммутаторах второй корзины (со слов сетевиков) и отбросу принятых пакетов на первой (от 10 до 100 в секунду, по сведениям системы мониторинга).
Важная рекомендация — не изменяйте настройки сети массово для всего кластера. Проверив на одном хосте и убедившись, что всё в порядке, мы отключили EtherChannel на всех остальных. И потеряли доступ ко всем, кроме первого. 15 мучительных минут, пока отходили от шока и возвращали конфигурацию обратно, никто, кроме счастливчиков размещённых на первом сервере, не мог работать. В дальнейшем меняли настройки по одному хосту, выводя его предварительно в Maintenance Mode. Параллельно я считал общие человеко-часы простоя, умножая 15 на 1300 (количество VDI) и деля на 60. Спасибо руководству за понимание… А ведь это было уже не первое потрясение, сязанное с виртуальными десктопами.
Кстати, уж не знаю почему, но пока я не пересоздал dvSwitch, хост при каждом ребуте выдавал ошибку: LACP Error: <что-то на тему того, что текущая конфигурация поддерживает IP Hash only>. Хотя EtherChannel был отключен. Новый dvSwitch такую ошибку не показывал. Перенос хостов и виртуальных машин в новый распределённый коммутатор сжёг ещё пачку нервных клеток, но всё обошлось.
Попутно я перенастроил использование аплинков. Перед началом работы все портгруппы были настроены одинаково:
Я сделал так:
В качестве способа организации балансировки — Route based on physical NIC load (следующий по списку интерфейс выбирается, если текущий загружен более чем на 70%).
Выводы — настройка балансировки и отказоустойчивости сети — процесс творческий. Но последующий монторинг показал, что при такой конфигурации а) исчезли потери пакетов первой блейд-корзины, б) балансировка нагрузки по аплинкам стала более равномерной, в) редко, но бывали ранее случаи, что хост вдруг становился недоступным. За последние несколько месяцев такого не было ни разу. г) Массовый vMotion (вывод сервера в Maintenance Mode, например) не оказывает влияния на трафик ВМ.
Преимуществ использования IP Hash, по сравнению с LB, я не вижу.
Мне сразу показалось, что 1,5 ГБ RAM для виртуальных десктопов на Windows 7 — это издевательство над пользователями. И скорее всего негативное влияние на дисковую подсистему из-за свопинга внутри ОС. Вот только излишков памяти не было. Риск потери отказоустойчивости и свопинга на уровне виртуальных машин был более негативным фактором. Идея пришла из новости об отключении средства Transparent Pages Sharing из настроек по умолчанию в грядущих версиях vSphere. Точнее, из дискуссии о ней на фейсбуке.
Краткое содержание:
Фича отключается, поскольку есть гипотетическая угроза безопасности (can be abused to gain unauthorized access to data *under certain highly controlled conditions*).
В большинстве реализаций технология действительно почти бесполезна с тех времён как появилась ASLR и поддержка больших страниц памяти. Поскольку найти две одинаковых страницы при размере оных в 2 МБ менее вероятно, чем в 4 КБ. А для серверной виртуализации страницы в 2 МБ куда критичнее, в плане производительности, чем экономия памяти.
Однако, почему бы не проверить её на кластере VDI?
Я внёс следующие изменения в Advanced Settings хоста:
Mem.AllocGuestLargePage = 0 вместо 1 — отключение больших страниц памяти
Mem.ShareScanGhz = 6 вместо 4 — повышение частоты сканирования
Mem.ShareScanTime = 30 вместо 60 — повышение скорости сканирования
Для компенсации увеличения нагрузки на процессор я отключил фишки vNuma, как бесполезные в случае ВМ, у которых меньше 8 vCPU. Данные настройки (вместе с настройками Path Selecting Policy) я распространил на все хосты с помощью Host Profiles. Результат можно увидеть на скрине ниже.
Пояснение по параметрам:
Если две ВМ совместно используют 100 МБ памяти, то параметр Shared будет равен 200 МБ, а Shared Common — 100 МБ.
Как можно увидеть из результатов мониторинга за месяц, Shared Common вырос в четыре раза, а Shared — в шесть. Суммарная экономия памяти составила почти 700 ГБ, то есть на 600 ГБ больше, по сравнению с состоянием на 26 октября. Это почти четверть всех ресурсов кластера. Правда средняя загрузка процессора выросла с 50-60% до 70-90%.
5 ноября наблюдается небольшой спад, поскольку Mem.ShareScanTime и Mem.ShareScanGhz пришлось вернуть в значения по умолчанию дабы снизить загрузку процессора. Сейчас она держится на 60-80% Тем не менее, экономия всё равно осталась значительная и появилась возможность всем машинам, имевшим 1,5 ГБ памяти увеличить её объём до 2.
Влияние этих изменений с точки зрения «отзывчивости» дисковой подсистемы можно оценить по картинке ниже. Приведено значение Read Latency для нескольких датасторов. К сожалению, на этот же период пришлись эксперименты с окнами обслуживания SCCM, которые давали ночные пики с фантастическими значениями до 80 секунд и сделали абсолютно непоказательными средние значения. По этой причине я не стал приводить сам график — ночные пики убили всю наглядность дневной нагрузки. Но можно оценить изменение по минимальным значениям времени отклика (первые колонки).
Первое время вообще непривычно было видеть показания средней Latency в «зелёной» зоне — 10-20 мс. Привычно было, что почти никогда не опускались ниже 30.
Вывод: не все распиаренные технологии так уж полезны, как о них говорят. Но и не все фичи, на которых ставят крест, и которые конкуренты, в данном случае VMware, хоронят на своих выступлениях так уж бессмысленны. Однако, надо знать их и понимать когда использовать. А для этого надо изучать настройки, параметры и свойства продукта, включая недокументированные. И тогда управление ИТ инфраструктурой не будет шаманством. А будет грамотным и творческим использованием знаний, что и составляет основу профессионализма.
Спасибо за внимание.
Полгода прошло с тех пор, как самый ответственный за виртуальную инфраструктуру человек уволился и оставил мне всё хозяйство и эксплуатационную документацию в виде списка служебных учёток. За это время был проведён ряд работ по укреплению фундамента, повышению надёжности и даже комфортности конструкции. Ключевыми моментами хочу поделиться.
Итак, дано:
Инфраструктура виртуализации VMware Enterprise Plus. Включает продуктив, тестовую зону и VDI. Последний реализован на базе продукта fujitsu Pano Logic, который уже 2 года как не обновляется и, судя по всему, не поддерживается.
Основной модернизируемый кластер — VDI, как самый объёмный критичный сервис и самый плотный по утилизации ресурсов. Реализован на базе полных клонов, ибо связанные клоны pano manager сам по себе не понимает, а покупать ещё и View бизнес не хочет.
В качестве СХД используется набор массивов EMC — несколько CX4-240 и пара VNX. А также есть такой изыск как IBM SVC. Используется для консолидации и виртуализации хранения (то есть lun монтируются со стораджей на SVC, там объединяются в пулы, а на этих пулах уже создаются новые LUN, отдаваемые серверам). Все хранилища подключены по FC SAN.
Так как документации не было, изучать, как что живёт и работает приходилось наживую. При этом некоторые безобидные, казалось бы, изменения, порой приводили к неожиданно неприятным последствиям, выявляя странные настройки и костыли.
Быстрая навигация:
1. Подсистема хранения
2. Сеть
3. Вычислительные ресурсы
1. Подсистема хранения
Это направление я начал ещё до ухода коллеги, поскольку SAN и была основной моей зоной ответственности.
1.1 VAAI
Первое, что меня удивило — использование большого количества датасторов маленького (1ТБ) размера. Зачем — никто объяснить не смог. Попытка консолидировать в датасторы побольше сразу выявила проблему — слишком большое количество scsi-блокировок, как следствие высокие latency и бут-штормы, как явление. Странным было то, что система хранения вела себя, как будто не поддерживала VAAI. Но в свойствах датасторов явно указано «Hardware Acceleration: Supported».
Понимание пришло, когда вводили новый хост в кластер. Коллега вспомнил, что перед эксплуатацией «надо ввести команду — отключить какую-то штуку, которая приводит к проблемам при работе с SVC». «Штукой» оказался параметр VMFS3.HardwareAcceleratedLocking, выставляемый в 0. Другими словами, отключалась, пожалуй, важнейшая функция VAAI — Atomic Test and Set (ATS) — позволяющая при изменении метаданных датастора (включение/выключение, миграция и растягивание тонких дисков ВМ) блокировать не весь датастор, а конкретные секторы на дисках.
Однако, эта настройка имела какие-то проблемы с SVC. По крайней мере, с той версией прошивки, что у нас была. Попытка обновления прошивок привела к смерти двух (из трёх обновлённых) нод, поддержка на данное оборудование закончилась, так что решили переносить датасторы напрямую на массивы EMC. Вообще так и осталось для меня непонятным — зачем надо было натягивать столь кривой слой виртуализации хранилищ поверх явно более продвинутого слоя сторадж пулов EMC.
Рекомендации: С точки зрения производительности, меньшее количество больших по размеру LUN выгоднее, чем большое количество маленьких — здесь и оверхед на обслуживание каждого LUN и распараллеливание запросов и ухудшение эффективности работы разных уровней кэша. (Рекомендация EMC по снижению нагрузки на SP: Reduce the number of LUNs by consolidating LUNs where possible. If a RAID group has multiple LUNs being used for the same host and application, then this can lead to linked contention, large seek distances and poor use of cache. Replacing these with fewer, larger LUNs will also reduce the amount of statistics which need to be monitored, therefore further reducing SP Utilization.)
При использовании систем виртуализации хранения, убедитесь, что они «интеллектуальнее» нижерасположенного уровня, или хотя бы не убивают функционал хранилищ. В нашем случае SVC явно была «глупее» массивов EMC, отказывалась видеть LUN'ы больше 2 ТБ и делала бессмысленным такие фичи, как автотиринг (и подозреваю, что Flash Cache).
Ну и конечно стоит убедиться, что оборудование хранения поддерживает VAAI, и, более того, что этот функционал не заблокирован на уровне инфраструктуры виртуализации.
1.2 Зонинг и распределение по массивам
Второй момент — странный разброс разных категорий данных по массивам. БД вперемешку с файл-серверами и VDI в хаотическом порядке были раскиданы по всем стораджам по принципу «где было место». Не говоря уж о том, что часть датасторов была подключена напрямую к EMC-массивам, а часть — через SVC.
После долгих миграций и перераспределений удалось распределить данные наиболее оптимальным образом — самые ресурсопотребляющие (продуктивные серверы и VDI) сложить на VNX'ы, а кларионы отдать под бэкапы и менее требовательные сервисы. В SVC остались только напрямую проброшенные в серверы LUN, все датасторы я из неё вынул. Число зон на коммутаторах сократилось с ~120 до ~75, с учётом того, что ранее встречались зоны типа «много таргетов — много инициаторов», а сейчас не более одного инициатора в зоне. Просто потому, что данные определённого типа, с которыми работали определённые серверы лежат теперь на одной СХД, а не на трёх разных.
В чём профит — лишние зоны создавали лишнюю нагрузку в SAN-сети, использование разнородной нагрузки (IO-интенсивной, типа БД и последовательной записи, типа бэкапов/файл-серверов) на одном массиве вредит производительности. Использование в одной зоне больше одного инициатора — bad practice.
1.3 Настройки Path Selection
# esxcli storage nmp device list на хостах показала, что
а) В большинстве своём для выбора путей до датасторов используется политика Round Robin,
б) Для части датасторов (первых шести) на первых двух хостах смена пути происходит через 3 IOPS
Path Selection Policy Device Config: {policy=iops,iops=3,
на остальных — дефолтное значение
Path Selection Policy Device Config: {policy=rr,iops=1000,
в) На последних пяти хостах кластера для части датасторов вообще использовался Fixed (всё общение с СХД идёт по одному пути, покуда он доступен).
Выбор Path Selection Policy определяется моделью и вендором СХД. В большинстве случаев, для конфигурация active-active используется round robin, ввиду какой-никакой, но балансировки нагрузки. По умолчанию смена пути происходит через 1000 iops. Однако в некоторых случаях это может привести к задержкам. Есть kb от VMware, где рекомендуется изменить это значение на 1. Есть тесты, показывающие, что производительность подсистемы хранения в этом случае реально выше.
Рекомендации: настраивайте multipathing в соответствии с рекомендациями вендоров для ваших конфигураций. И следите за тем, чтобы на всех хостах они были одинаковыми. Хорошо в этом помогают Host Profiles в VMware.
2. Сеть
В целях настройки балансировки нагрузки, все коммутаторы блейд-корзины кластера VDI были объединены в стек, организован EtherChannel и load balancing в разделе Teaming and Failover был сконфигурирован как Route Based on IP Hash. Дело в том, что IP Hash работает только поверх EtherChannel и с EtherChannel совместим только IP Hash. Однако когда кластер вырос до второй блейд-корзины, коммутаторы которой не поддерживали EtherChannel, появилась проблема. Проблема проявлялась в виде жёсткого MAC-флаппинга на коммутаторах второй корзины (со слов сетевиков) и отбросу принятых пакетов на первой (от 10 до 100 в секунду, по сведениям системы мониторинга).
Важная рекомендация — не изменяйте настройки сети массово для всего кластера. Проверив на одном хосте и убедившись, что всё в порядке, мы отключили EtherChannel на всех остальных. И потеряли доступ ко всем, кроме первого. 15 мучительных минут, пока отходили от шока и возвращали конфигурацию обратно, никто, кроме счастливчиков размещённых на первом сервере, не мог работать. В дальнейшем меняли настройки по одному хосту, выводя его предварительно в Maintenance Mode. Параллельно я считал общие человеко-часы простоя, умножая 15 на 1300 (количество VDI) и деля на 60. Спасибо руководству за понимание… А ведь это было уже не первое потрясение, сязанное с виртуальными десктопами.
Кстати, уж не знаю почему, но пока я не пересоздал dvSwitch, хост при каждом ребуте выдавал ошибку: LACP Error: <что-то на тему того, что текущая конфигурация поддерживает IP Hash only>. Хотя EtherChannel был отключен. Новый dvSwitch такую ошибку не показывал. Перенос хостов и виртуальных машин в новый распределённый коммутатор сжёг ещё пачку нервных клеток, но всё обошлось.
Попутно я перенастроил использование аплинков. Перед началом работы все портгруппы были настроены одинаково:
Я сделал так:
В качестве способа организации балансировки — Route based on physical NIC load (следующий по списку интерфейс выбирается, если текущий загружен более чем на 70%).
Выводы — настройка балансировки и отказоустойчивости сети — процесс творческий. Но последующий монторинг показал, что при такой конфигурации а) исчезли потери пакетов первой блейд-корзины, б) балансировка нагрузки по аплинкам стала более равномерной, в) редко, но бывали ранее случаи, что хост вдруг становился недоступным. За последние несколько месяцев такого не было ни разу. г) Массовый vMotion (вывод сервера в Maintenance Mode, например) не оказывает влияния на трафик ВМ.
Преимуществ использования IP Hash, по сравнению с LB, я не вижу.
3. Вычислительные ресурсы
Мне сразу показалось, что 1,5 ГБ RAM для виртуальных десктопов на Windows 7 — это издевательство над пользователями. И скорее всего негативное влияние на дисковую подсистему из-за свопинга внутри ОС. Вот только излишков памяти не было. Риск потери отказоустойчивости и свопинга на уровне виртуальных машин был более негативным фактором. Идея пришла из новости об отключении средства Transparent Pages Sharing из настроек по умолчанию в грядущих версиях vSphere. Точнее, из дискуссии о ней на фейсбуке.
Краткое содержание:
Фича отключается, поскольку есть гипотетическая угроза безопасности (can be abused to gain unauthorized access to data *under certain highly controlled conditions*).
В большинстве реализаций технология действительно почти бесполезна с тех времён как появилась ASLR и поддержка больших страниц памяти. Поскольку найти две одинаковых страницы при размере оных в 2 МБ менее вероятно, чем в 4 КБ. А для серверной виртуализации страницы в 2 МБ куда критичнее, в плане производительности, чем экономия памяти.
Однако, почему бы не проверить её на кластере VDI?
Я внёс следующие изменения в Advanced Settings хоста:
Mem.AllocGuestLargePage = 0 вместо 1 — отключение больших страниц памяти
Mem.ShareScanGhz = 6 вместо 4 — повышение частоты сканирования
Mem.ShareScanTime = 30 вместо 60 — повышение скорости сканирования
Для компенсации увеличения нагрузки на процессор я отключил фишки vNuma, как бесполезные в случае ВМ, у которых меньше 8 vCPU. Данные настройки (вместе с настройками Path Selecting Policy) я распространил на все хосты с помощью Host Profiles. Результат можно увидеть на скрине ниже.
Пояснение по параметрам:
Если две ВМ совместно используют 100 МБ памяти, то параметр Shared будет равен 200 МБ, а Shared Common — 100 МБ.
Как можно увидеть из результатов мониторинга за месяц, Shared Common вырос в четыре раза, а Shared — в шесть. Суммарная экономия памяти составила почти 700 ГБ, то есть на 600 ГБ больше, по сравнению с состоянием на 26 октября. Это почти четверть всех ресурсов кластера. Правда средняя загрузка процессора выросла с 50-60% до 70-90%.
5 ноября наблюдается небольшой спад, поскольку Mem.ShareScanTime и Mem.ShareScanGhz пришлось вернуть в значения по умолчанию дабы снизить загрузку процессора. Сейчас она держится на 60-80% Тем не менее, экономия всё равно осталась значительная и появилась возможность всем машинам, имевшим 1,5 ГБ памяти увеличить её объём до 2.
Влияние этих изменений с точки зрения «отзывчивости» дисковой подсистемы можно оценить по картинке ниже. Приведено значение Read Latency для нескольких датасторов. К сожалению, на этот же период пришлись эксперименты с окнами обслуживания SCCM, которые давали ночные пики с фантастическими значениями до 80 секунд и сделали абсолютно непоказательными средние значения. По этой причине я не стал приводить сам график — ночные пики убили всю наглядность дневной нагрузки. Но можно оценить изменение по минимальным значениям времени отклика (первые колонки).
Первое время вообще непривычно было видеть показания средней Latency в «зелёной» зоне — 10-20 мс. Привычно было, что почти никогда не опускались ниже 30.
Вывод: не все распиаренные технологии так уж полезны, как о них говорят. Но и не все фичи, на которых ставят крест, и которые конкуренты, в данном случае VMware, хоронят на своих выступлениях так уж бессмысленны. Однако, надо знать их и понимать когда использовать. А для этого надо изучать настройки, параметры и свойства продукта, включая недокументированные. И тогда управление ИТ инфраструктурой не будет шаманством. А будет грамотным и творческим использованием знаний, что и составляет основу профессионализма.
Спасибо за внимание.
