Comments 7
Отличная статья!
можете рассказать подробнее про рекомендацию использовать большой по размеру LUN.
Если иметь ввиду датасторы, какой у вас средний размер датастора? и по какому принципу вы консолидировали lun'ы (маленькие датасторы) в большие?
И какое количество виртуальных машин на датастор вы используете?
последний вопрос потому, что в RVTools по умолчанию стоит параметр Number of running VMs per datastore = 16
можете рассказать подробнее про рекомендацию использовать большой по размеру LUN.
Если иметь ввиду датасторы, какой у вас средний размер датастора? и по какому принципу вы консолидировали lun'ы (маленькие датасторы) в большие?
И какое количество виртуальных машин на датастор вы используете?
последний вопрос потому, что в RVTools по умолчанию стоит параметр Number of running VMs per datastore = 16
Не более 16 машин на датастор — это старые best practices, основанные на проблеме SCSI Reservation Conflicts.
Сейчас, с появлением VAAI и ATS на LUN можно размещать гораздо большее количество ВМ. От неограниченного отделяют возможности дисков и уровня RAID (1), а также очередь одновременных запросов к LUN (2):
1) Исходя из того, что SAS15k = 175 IOPS, SAS10k = 126 IOPS, SATA/NL-SAS = 75 IOPS, Write Penalty выбранного RAID и соотношения записи и чтения, а также средней IO-нагрузки каждой ВМ, считаем количество дисков, необходимых под LUN и создаём, невзирая на размер. В случае умных mid-range и выше массивов, которые виртуализируют дисковые ресурсы и размазывают LUN по максимальному количеству шпинделей, этот расчёт становится неактуальным. Учитывая, что никто толком не знает, как точно они это делают (и как экстендят пулы при добавлении дисков), а также дополнительные примочки типа разных уровней кэша, оптимальный размер LUN познаётся опытным путём, в зависимости от вендора СХД и конфигурации.
2) Очередь одновременных запросов к каждому LUN равна 32, соответственно, число ВМ на LUN зависит от количества OutstandingIO, генерируемых этими машинами и количества хостов, работающих с этим LUN. Например:
outstandingIO=32 — одна машина на LUN.
outstandingIO=16 — две машины, если обе на одном хосте. Четыре, если хоста два. Но такие показатели имеют место у очень нагруженных БД.
Если принять, что хостов у нас 15, а у VDI этот параметр, ну пусть 4 с запасом, то число их на датастор будет 15 * 32 / 4 = 120. Скорее всего раньше упрёмся по iops, а это пункт 1).
У нас под VDI сейчас созданы 4ТБ датасторы по 60-70 машин на каждом. Было плотнее, но latency был выше, поэтому добавил пару новых lun и размазал. Под серверы 6ТБ датасторы и машинами они наполняются пока место позволяет. Несколько особо чувствительных виртуальных серверов размещены на небольших датасторах с Hi-Level Tier.
Сейчас, с появлением VAAI и ATS на LUN можно размещать гораздо большее количество ВМ. От неограниченного отделяют возможности дисков и уровня RAID (1), а также очередь одновременных запросов к LUN (2):
1) Исходя из того, что SAS15k = 175 IOPS, SAS10k = 126 IOPS, SATA/NL-SAS = 75 IOPS, Write Penalty выбранного RAID и соотношения записи и чтения, а также средней IO-нагрузки каждой ВМ, считаем количество дисков, необходимых под LUN и создаём, невзирая на размер. В случае умных mid-range и выше массивов, которые виртуализируют дисковые ресурсы и размазывают LUN по максимальному количеству шпинделей, этот расчёт становится неактуальным. Учитывая, что никто толком не знает, как точно они это делают (и как экстендят пулы при добавлении дисков), а также дополнительные примочки типа разных уровней кэша, оптимальный размер LUN познаётся опытным путём, в зависимости от вендора СХД и конфигурации.
2) Очередь одновременных запросов к каждому LUN равна 32, соответственно, число ВМ на LUN зависит от количества OutstandingIO, генерируемых этими машинами и количества хостов, работающих с этим LUN. Например:
outstandingIO=32 — одна машина на LUN.
outstandingIO=16 — две машины, если обе на одном хосте. Четыре, если хоста два. Но такие показатели имеют место у очень нагруженных БД.
Если принять, что хостов у нас 15, а у VDI этот параметр, ну пусть 4 с запасом, то число их на датастор будет 15 * 32 / 4 = 120. Скорее всего раньше упрёмся по iops, а это пункт 1).
У нас под VDI сейчас созданы 4ТБ датасторы по 60-70 машин на каждом. Было плотнее, но latency был выше, поэтому добавил пару новых lun и размазал. Под серверы 6ТБ датасторы и машинами они наполняются пока место позволяет. Несколько особо чувствительных виртуальных серверов размещены на небольших датасторах с Hi-Level Tier.
Можно ещё играться с разными длинами очереди, но в подавляющем большинстве случаев лучше не надо.
Неплохая статья для получения представления о разного уровня очередях тут.
Неплохая статья для получения представления о разного уровня очередях тут.
знакомые графики veeam one. )
Познавательная статья, спасибо!
А можете описать общие впечатления от работы с Pano Logic? Какие-нибудь явные особенности и/или проблемы с ней? Система старая и давно не поддерживается, но все-равно интересно. И одно из блейд-шасси случайно не Fujitsu BX900? :)
А можете описать общие впечатления от работы с Pano Logic? Какие-нибудь явные особенности и/или проблемы с ней? Система старая и давно не поддерживается, но все-равно интересно. И одно из блейд-шасси случайно не Fujitsu BX900? :)
Скажу прямо: восторга не испытываю. В своё время, может, и неплохой был продукт, но сейчас совсем убого.
1. Управление через писанный на Flash web-интерфейс. Ест много памяти, безбожно тормозит, имеет минимум возможностей по управлению.
2. Никаких тонких настроек. Даже «толстых» минимум — только управление пулами VDI и создание кластера. Сами серверы управления — апплаенсы, то есть блэкбоксы. Из доступной документации только он-лайн хелп, очень куцый. Единственный воркэраунд на все проблемы, который мне передал ушедший коллега: «перезагрузить оба сервера одновременно».
3. Буквально сегодня случился инцидент — с часть зеро-клиентов после ребута не смогла подцепиться. Моргали жёлтым глазом, будто не могли получить ip. Так как буквально месяц назад был прецедент с DHCP, наехали на DHCP-мастера и сетевиков, но оказалось, у них всё в порядке. В логах Pano сообщения, что client exited abnormally with exit code 134. Но что бы это значило, тайна великая есть.
Оказалось, место закончилось в рутовом разделе. java дампами забила.
4. Ну и отсутствие поддержки linked-клонов тоже жёсткий минус. Конечно, можно купить view и интегрировать (если новая версия сможет интегрироваться. Citix уже не может), но нелепо покупать два решения VDI только ради зеро-клиентов. Поэтому живём на старом Pano :(
1. Управление через писанный на Flash web-интерфейс. Ест много памяти, безбожно тормозит, имеет минимум возможностей по управлению.
2. Никаких тонких настроек. Даже «толстых» минимум — только управление пулами VDI и создание кластера. Сами серверы управления — апплаенсы, то есть блэкбоксы. Из доступной документации только он-лайн хелп, очень куцый. Единственный воркэраунд на все проблемы, который мне передал ушедший коллега: «перезагрузить оба сервера одновременно».
3. Буквально сегодня случился инцидент — с часть зеро-клиентов после ребута не смогла подцепиться. Моргали жёлтым глазом, будто не могли получить ip. Так как буквально месяц назад был прецедент с DHCP, наехали на DHCP-мастера и сетевиков, но оказалось, у них всё в порядке. В логах Pano сообщения, что client exited abnormally with exit code 134. Но что бы это значило, тайна великая есть.
Оказалось, место закончилось в рутовом разделе. java дампами забила.
4. Ну и отсутствие поддержки linked-клонов тоже жёсткий минус. Конечно, можно купить view и интегрировать (если новая версия сможет интегрироваться. Citix уже не может), но нелепо покупать два решения VDI только ради зеро-клиентов. Поэтому живём на старом Pano :(
Да, все так. На мой взгляд продукт имел хороший потенциал (наверное кто-то в Fujitsu тоже это видел), но умер не успев дорасти даже до просто стабильного решения. Его полная закрытость (менеджер подключений и протокол PDP) не позволяют как-либо модернизировать его. Connection Manager версии 6 может интегрироваться с View не новее 5.0.1
Sign up to leave a comment.
Настройка виртуальной инфраструктуры: оптимизация кластера VDI