Новые документы о виртуализации
 | VMware Virtual SAN 6.2 Network Design Guide (скачать)Компания VMware выпустила весьма полезный документ "VMware Virtual SAN 6.2
Network Design Guide", в котором приведены конкретные рекомендации по настройке и конфигурации сети при организации отказоустойчивых кластеров хранилищ.
Из рекомендаций в документе:
- Отключите Flow Control на физическом оборудовании, у Virtual SAN есть свой механизм контроля перегрузки канала.
- Используйте vSphere Distributed Switch (VDS) совместно с Virtual SAN.
- Настройте Load Based Teaming (LBT), который балансирует нагрузку, в зависимости от загрузки физического адаптера (похоже на Virtual Port ID, только привязка к порту пересматривается каждые 30 секунд).
- Если используете несколько кластеров Virtual SAN - помещайте трафик каждого из них в отдельный VLAN.
- Если в датацентре используются большие кадры jumbo frames - используйте их в кластере Virtual SAN, но если не используются - то отдельно включать их не надо.
- Включите Cisco Discovery Protocol (CDP) и Link Layer Discovery
Protocol (LLDP) в режимах и приема, и передачи.
В документе присутствует еще несколько интересных рекомендаций, прочитать которые будет особенно интересно администраторам крупных инфраструктур и больших кластеров Virtual SAN. |  | vSphere Design Pocketbook v3 (скачать)Известный многим из вас блоггер Фрэнк Деннеман (Frank Denneman) на днях анонсировал третье издание книги о проектировании виртуальной инфраструктуры VMware - vSphere Design Pocketbook v3, которая построена на базе материалов авторов, пишущих о виртуализации в своих блогах или на других ресурсах.
Книга представляет собой сборник статей известных блоггеров и специалистов в области построения виртуальной инфраструктуры, которые широко известны в медиа-пространстве. Среди них такие известные ребята, как William Lam, Matt Leibowitz, Frank Denneman и другие.
Книга доступна бесплатно в электронном виде по этой ссылке, а в печатном виде будет распространяться на конференции EMC World. В книге 157 страниц рекомендаций по дизайну инфраструктуры виртуализации в формате блог-записей, в которых авторы стараются быть максимально конкретными и пишут по сути (со скриншотами, графиками и таблицами). |  | StarWind Virtual SAN VVOLs Technical Preview Guide (скачать)У компании StarWind есть специальный документ "StarWind Virtual SAN VVOLs Technical Preview Guide", рассказывающий о том, как попробовать виртуальные тома VVols для vSphere в режиме технологического превью в рамках тестовой инфраструктуры из одного хост-сервера.
Для тестирования нужно использовать виртуальный модуль StarWind VSA, который развертывается как виртуальная машина в формате OVF.
Для развертывания тестового стенда вам потребуется один сервер VMware ESXi 6.0 под управлением vCenter 6 в следующей минимальной конфигурации:
- 8 ГБ RAM
- 2GHz+ 64-bit x86 Dual Core CPU
- 2 vCPU, 4 ГБ RAM и 50 ГБ хранилища для машины StarWind
- Выделенный vSwitch для трафика ISCSI
|  | VMware Lifecycle Product Matrix (скачать)Некоторое время назад мы писали о документе VMware Lifecycle Product Matrix, описывающем жизненный цикл продуктов VMware. В январе 2016 года вышла обновленная версия этого документа:
Напомним основные стадии жизненного цикла продуктов VMware:
- Genetral Availability - официальная доступность продукта для загрузки, с даты которой начинается General Support Phase.
- General Support Phase - эта фаза начинается после выпуска мажорного релиза (GA) и длится определенное время. В этот период пользователи, купившие официальную поддержку VMware (а не купить ее нельзя) получают апдейты и апгрейды, багофиксы и фиксы безопасности, а также техническое сопровождение в соответствии с Terms and Conditions.
- Technical Guidance Phase - эта фаза (если она доступна) начинается с момента окончания предыдущей фазы и длится заданное время. Здесь уже предоставляются инструкции через портал самообслуживания, а по телефону звонки не принимаются. В этой фазе можно открыть кейс в техподдержке онлайн, но только для поддерживаемых конфигураций. В этой фазе VMware не оказывает поддержки, касающейся оборудования, обновлений ОС, патчей безопасности или багофиксов (если о другом не объявлено дополнительно). Предполагается, что в этой фазе пользователи используют стабильные версии ПО и конфигураций при нормальных (не повышенных) нагрузках.
- End of Support Life (EOSL) - в этой фазе продукт уже не поддерживается VMware. Это означает окончание первых двух фаз. Кроме этого, здесь происходит прекращение продаж продукта.
- End of Availability (EOA) / End Of Distribution (EOD) - в этом режиме продукт уже не поддерживается, и он недоступен на сайте VMware, то есть его, попросту говоря, нельзя скачать.
|  | VMware vSphere 6 Fault Tolerance Architecture and Performance (скачать)Компания VMware выпустила очень интересный документ "VMware vSphere 6
Fault Tolerance
Architecture and Performance", посвященный производительности технологии VMware Fault Tolerance (FT), которая позволяет обеспечивать непрерывную доступность виртуальных машин, даже в случае отказа хост-сервера VMware ESXi. Делается это за счет техники Fast Checkpointing, по своей сути похожей на комбинацию Storage vMotion и vMotion, которая копирует состояние дисков, памяти, процессорных команд и сетевого трафика на резервную машину, поддерживая ее в полностью синхронизированном с первой состоянии. На данный момент vSphere 6 FT поддерживает виртуальные машины с конфигурацией до 4 vCPU и до 64 ГБ оперативной памяти на хост ESXi.
Результаты тестирования очень полезны - теперь администраторы смогут закладывать потери производительности на поддержание FT-кластера в архитектуру планируемой инфраструктуры для бизнес-критичных приложений.
|  | Installing ESXi Using PXE (скачать)Когда вы ставите один сервер VMware ESXi, то проще всего сделать это, смонтировав ISO-образ через iLO или подобную консоль, либо воткнув загрузочную флешку непосредственно в сервер. Но если у вас несколько хост-серверов ESXi, то делать так уже несолидно для опытного администратора. В целях ускорения процесса он использует процедуру загрузки установщика хоста по сети через механизм PXE, а самые крутые администраторы уже используют средство Auto Deploy, у которого сравнительно недавно появился GUI.
На эту тему компания VMware выпустила очень полезный документ "Installing ESXi Using PXE", в котором эта процедура расписывается по шагам (как для BIOS, так и для UEFI-хостов):
1. Администратор загружает целевой хост ESXi.
2. Этот хост делает DHCP-запрос.
3. DHCP-сервер отвечает с IP-параметрами и расположением TFTP-сервера, который содержит загрузчик.
4. ESXi обращается к серверу TFTP и запрашивает файл загрузчика, который указал DHCP-сервер.
5. TFTP-сервер посылает загрузчик хосту ESXi, который исполняет его. Начальный загрузчик догружает дополнительные компоненты с TFTP-сервера.
6. Загрузчик ищет конфигурационный файл на TFTP-сервере, скачивает ядро и другие компоненты ESXi с HTTP-сервера, который размещен на TFTP-сервере, и запускает ядро на хосте ESXi.
7. Установщик ESXi запускается в интерактивном режиме, либо используя kickstart-скрипт, который указан в конфигурационном файле.
Для автоматизации задач по подготовке ISO-образа ESXi к загрузке через PXE вы можете использовать вот этот полезный скрипт.
|  | VMware App Volumes Reference Architecture (скачать)Какое-то время назад мы писали о технологии доставки приложений пользователям инфраструктуры настольных ПК предприятия - VMware App Volumes (ранее это называлось Cloud Volumes). Суть ее заключается в том, что виртуализованные и готовые к использованию приложения VMware ThinApp доставляются пользователям в виде подключаемых виртуальных дисков к машинам.
Недавно компания VMware выпустила документ "VMware App Volumes Reference Architecture", в котором объясняется работа технологии App Volumes, рассматривается референсная архитектура этого решения, а также проводится тестирование производительности доставляемых таким образом приложений по сравнению с их нативной установкой внутри виртуальных ПК.
В качестве референсной архитектуры используется инфраструктура из 2000 виртуальных ПК, запущенных на 18 хостах ESXi инфраструктуры VMware Horizon View.
Для генерации нагрузки использовались различные сценарии пользовательского поведения, создаваемые с помощью средства Login VSI, ставшего уже стандартом де-факто для тестирования VDI-инфраструктур, развернутого на трех хост-серверах.
Здесь описаны 3 варианта тестирования:
- Приложения, нативно установленные в виртуальных ПК.
- Приложения App Volumes, использующие один AppStack, содержий основные приложения пользователей.
- Приложения App Volumes, распределенные по трем различным AppStack.
В целом-то, нельзя сказать, что потери производительности незначительные - они, безусловно, чувствуются. Но радует, что они фиксированы и хорошо масштабируются при увеличении числа одновременных сессий в VDI-инфраструктуре.
Документ очень полезен для оценки потерь производительности с точки зрения User Experience при использовании App Volumes по сравнению с традиционной доставкой приложений. |  | VMware NSX for vSphere Network Virtualization Design Guide версия 3.0 (скачать)Для тех из вас, кто использует в производственной среде или тестирует решение VMware NSX для виртуализации сетей своего датацентра, компания VMware подготовила полезный документ "VMware NSX for vSphere Network Virtualization Design Guide", который вышел уже аж в третьей редакции.
Документ представляет собой рефернсный дизайн инфраструктуры виртуализации сетей в датацентре и описывает архитектуру решения NSX на физическом и логическом уровнях.
В новой версии документа появилась следующая информация для сетевых архитекторов:
- сайзинг решения NSX для небольших датацентров
- лучшие практики маршрутизации
- микросегментация и архитектура компонента обеспечения безопасности среды Service Composer
Документ содержит ни много ни мало 167 страниц.
|  | Virtual Printing Solutions with View in Horizon 6 (скачать)Многие из вас знают, что в решении VMware Horizon View есть две полезных возможности, касающихся функций печати из виртуального ПК пользователя - это перенаправление принтеров (Printer redirection) и печать на основе местоположения (Location based printing).
Printer redirection
Эта возможность позволяет перенаправить печать из виртуального ПК к локальному устройству пользователя, с которого он работает, и к которому подключен принтер уже физически. Функция поддерживается не только для Windows-машин, но и для ПК с ОС Linux и Mac OS X. Работает эта фича как для обычных компьютеров, так и для тонких клиентов (поддерживается большинство современных принтеров).
При печати пользователь видит принтер хоста не только в диалоге печати приложения, но и в панели управления. При этом не требуется в виртуальном ПК иметь драйвер принтера - достаточно, чтобы он был установлен на хостовом устройстве.
Перенаправление принтеров полезно в следующих случаях:
- в общем случае, когда к физическому ПК пользователя привязан принтер
- когда пользователь работает из дома со своим десктопом и хочет что-то распечатать на домашнем принтере
- работники филиала печатают на локальных принтерах, в то время, как сами десктопы расположены в датацентре центрального офиса
Location based printing
Эта фича позволяет пользователям виртуальных ПК печатать на тех принтерах, которые находятся географически ближе к нему, чтобы не бегать, например, на другой этаж офисного здания, чтобы забирать распечатанное, когда есть принтеры поблизости. Правила такой печати определяются системным администратором.
Для функции Location based printing задания печати направляются с виртуального ПК напрямую на принтер, а значит нужно, чтобы на виртуальном десктопе был установлен драйвер этого принтера.
Есть 2 типа правил Location based printing:
- IP-based printing - используется IP-адрес принтера для определения правил маппинга принтера к десктопам.
- UNC-based printing - используются пути в формате Universal Naming Convention (UNC) для определения правил маппинга принтеров.
Запрос пользователя с хостового устройстра через Horizon Client передается к View Agent, который через взаимодействие с приложением передает задание драйверу принтера в гостевой ОС с учетом правил маппинга принтеров, а дальше уже обработанное задание идет на печать.
Ну а о том, как настраивать обе техники печати из виртуальных ПК вы можете прочитать в документе.
|  | VMware Virtual SAN Stretched Cluster Bandwidth Sizing Guidance (скачать)Мы уже писали о том, что "растянутый" кластер VMware HA Stretched Cluster прекрасно работает и поддерживается вместе с отказоустойчивыми хранилищами Virtual SAN. Также мы писали о документе с лучшими практиками по построению таких кластеров, для которых требуется обеспечивать максимальную производительность.
Однако многие задаются вопросом - а как планировать ширину канала между площадками таких растянутых кластеров, чтобы обеспечить необходимую пропускную способность для синхронизации узлов кластера VMware Virtual SAN? В помощь таким пользователям компания VMware выпустила интересный документ "VMware Virtual SAN Stretched Cluster Bandwidth Sizing Guidance", в котором даются конкретные параметры и формулы для расчета необходимой пропускной способности между площадками.
Как известно, реальный трафик состоит из отношения операций чтения и записи, которое зависит от характера нагрузки. Например, в VDI-среде это отношение составляет примерно 30/70, то есть 30% - это операции чтения (read), а 70% - операции записи (write).
В среде растянутого кластера данные виртуальной машины всегда читаются с локальных узлов VSAN - это называется Read Locality. Ну а для операций записи, само собой, нужна определенная пропускная способность на другую площадку. Она рассчитывается как:
B = Wb * md * mr
где:
- Wb - полоса записи данных.
- md - множитель данных, он зависит от потока метаданных кластера VSAN и сервисных операций. VMware рекомендует использовать значение 1,4 для этого параметра.
- mr - множитель ресинхронизации. Для целей ресинхронизации VMware рекомендует заложить в канал еще 25%, то есть использовать значение этого параметра 1,25.
Например, рабочая нагрузка у вас составляет 10 000 IOPS на запись (10 тысяч операций в секунду). Возьмем типичный размер операции записи в 4 КБ и получим параметр Wb:
Wb = 10 000 * 4KB = 40 MB/s = 320 Mbps
Мегабайты в секунду переводятся в мегабиты умножением на 8. Ну и заметим, что требование канала по записи нужно умножать на 1,4*1,25 = 1,75. То есть канал нужно закладывать почти в 2 раза больше от требований по записи данных.
Теперь считаем требуемую пропускную способность канала между площадками:
B = Wb * md * mr = 320 Mbps * 1,4 * 1,25 = 560 Mbps
Ну а в самом документе вы найдете еще больше интересных расчетов и примеров. | |
|
|  |
|
RSS
