Компания StarWind Software известна своим лидирующим в отрасли решением Virtual SAN, которое позволяет создать отказоустойчивый кластер хранилищ для виртуальных машин на различных платформах. Сегодня мы расскажем о средстве StarWind Virtual Tape Library (VTL), реализующем виртуальную ленточную библиотеку, и его совместном использовании с решением для резервного копирования и репликации Veeam Backup and Replication.
Еще очень давно, 8 лет назад, компания VMware развивала мобильный клиент (см. также тут) для управления инфраструктурой VMware vSphere, но забросила это дело на некоторое время.
И вот совсем недавно на сайте проекта VMware Labs появилось средство vSphere Mobile Client 1.1. Это очередной подход VMware к управлению виртуальной средой через мобильные приложения для iOS и Android.
Само собой, vSphere Mobile Client предоставляет лишь малую часть функций полноценного клиента (но для мобильных устройств это и не нужно), вот основные из них:
Просмотр информации и виртуальных машинах - просмотр статуса ВМ (включено/выключено), использования ресурсов и конфигурации машин.
Управление ВМ - операции с питанием (в том числе, перезагрузка). Возможность найти виртуальную машину с помощью поиска. Если вы свайпните влево карточку с виртуальной машиной, то получите скриншот ее консоли, который можно сохранить.
Мониторинг задач - можно "подписаться" на любую запущенную задачу и получать нотификации на телефон о том, когда она завершится. При этом неважно, что ваш девайс находится в неактивном режиме или в данный момент вы работаете с другим приложением.
Графики производительности - можно отслеживать использование ресурсов виртуальными машинами в реальном времени, либо в разрезе дня, недели, месяца или года назад. Счетчики включают в себя метрики CPU, памяти, хранилищ и сети. Также на дэшборде можно посмотреть общее использование ресурсов vCenter.
Ссылки на загрузку vSphere Mobile Client:
Android - до того, как устанавливать клиент, вам надо присоединиться к этой группе Google Groups, члены которой принимают участие в альфа-тестировании.
Чтобы получать пуш-уведомления на ваши устройства, нужно будет поднять vSphere Mobile Client Notification Service в виде контейнера Docker. О том, как это сделать написано тут, а скачать сам контейнер можно на странице vSphere Mobile Client.
Весной этого года мы писали о новой версии продукта VMware vRealize Network Insight (vRNI) 4.1, который позволяет системным и сетевым администраторам (а также администраторам информационной безопасности) наблюдать за сетевым взаимодействием в рамках виртуальной инфраструктуры и предпринимать действия по ее защите.
На днях VMware объявила о выпуске vRNI 4.2, давайте посмотрим, что там появилось нового.
1. Новые Data Sources
Теперь данные можно получать из следующих систем:
Fortinet Firewall
Можно получить полный доступ к средствам управления Fortinet FortiManager, который управляет сетевыми экранами FortiGate. Это позволяет видеть всю инфраструктуру в контексте фаерволов, мгновенно видеть, какие правила привязаны к ВМ, получать сетевую топологию и многое другое.
OpenShift Container Platform
В прошлой версии была добавлена поддержка VMware Enterprise PKS и ванильной инсталляции Kubernetes, а теперь поддержка была расширена функциями сетевой видимости, средствами обеспечения безопасности приложений, планирования миграции и решения проблем для небольших нагрузок.
Кастомные Data Sources
Это называется User Assisted Network Information (U-AN-I). В рамках этого механизма вы можете ввести информацию о собственном коммутаторе или маршрутизаторе, который в дальнейшем будет добавлен в список поддерживаемых устройств. Но еще до полноценной поддержки это даст вам возможность просматривать пути VM-to-VM, дэшборд для коммутатора/маршрутизатора в рамках сетевой топологии, список всех интерфейсов, маршрутов, список VRF и т.п.
Также есть Python-библиотека, которая позволит автоматизировать сбор информации с устройств (маршруты, интерфейсы и т.д.) и загрузить ее в Network Insight. Саму эту задачу можно добавить в планировщик для регулярного обновления.
2. Метрики Network Latency.
Network Insight 4.2 представляет метрику задержки в 2 формах: TCP Round-Trip Time (RTT), которая привязана к сетевому потоку и метрика latency между отдельными компонентами (виртуальные и физические адаптеры NIC в рамках хоста ESXi).
Метрика TCP RTT может быть найден на дэшборде потока:
Также можно найти все потоки, время RTT которых больше 10 мс, следующей командой в поиске:
Average Tcp RTT of flow where Average Tcp RTT > 10ms
Кроме того, есть еще один наглядный способ увидеть все сетевые потоки вашей инфраструктуры на одной странице - надо пойти в Flow Insights и выбрать диаграмму Network Performance:
Из этого представления вы сразу поймете, какие потоки отрабатывают с самой большой задержкой, после чего можно углубиться в структуру потока и понять причину, по которой эта задержка столь велика.
С точки зрения измерения latency между компонентами, сейчас доступны следующие связки: vNIC к pNIC, pNIC к vNIC и vNIC к vNIC.
Надо отметить, что для получения данной информации вам потребуется NSX Data Center for vSphere версии 6.4.5 или выше.
3. Новые функции Application Discovery.
В Network Insight 4.1 появилась возможность обнаружения приложений без использования агентов с помощью трех методов:
Использование тэгов рабочей нагрузки (workload tags)
Иморт приложений из ServiceNow CMDB
Использование паттерн наименования (naming convention)
Последний метод особенно актуален для облачных систем (например, инстансы AWS EC2), поэтому раньше пользователи должны были сами конструировать регулярные выражения, что непросто.
Теперь же в мастере application discovery wizard для этого есть Pattern Builder:
Также, начиная с vRNI 4.2, вы можете сохранять application discovery runs как шаблоны, чтобы не конструировать регулярные выражения заново, что очень удобно.
4. Улучшения дэшборда Application Dashboard.
Это лучший дэшборд vRNI, который показывает все потоки между всеми обнаруженными приложениями в вашей инфраструктуре. В версии vRNI 4.1 его возможности были несколько ограничены, теперь же каждый поток визуализуется и детализируется, когда вы увеличиваете диаграмму и масштабируете его.
При этом с увеличением конкретного компонента увеличивается степень детализации, то есть включаются все виртуальные машины, контейнеры и т.п.
Полный список улучшений и нововведений находится в Release Notes. Скачать vRealize Network Insight 4.2 можно по этой ссылке.
Многие из администраторов VMware vSphere знают про механизм Storage I/O Control (SIOC) в платформе VMware vSphere (см. также наш пост здесь). Он позволяет приоритезировать ввод-вывод для виртуальных машин в рамках хоста, а также обмен данными хостов ESXi с хранилищами, к которым они подключены.
Сегодня мы поговорим о SIOC версии 2 и о том, как он взаимодействует с политиками Storage Policy Based Management (SPBM). Начать надо с того, что SIOC v2 полностью основан на политиках SPBM, а точнее является их частью. Он позволяет контролировать поток ввода-вывода на уровне виртуальных машин.
SIOC первой версии работает только с томами VMFS и NFS, тома VVol и RDM пока не поддерживаются. Он доступен только на уровне датасторов для регулирования потребления его ресурсов со стороны ВМ, настраиваемого на базе шар (shares). Там можно настроить SIOC на базе ограничения от пиковой пропускной способности (throughput) или заданного значения задержки (latency):
На базе выделенных shares виртуальным машинам, механизм SIOC распределит пропускную способность конкретного хранилища между ними. Их можно изменять в любой момент, перераспределяя ресурсы, а также выставлять нужные лимиты по IOPS:
Надо отметить, что SIOC v1 начинает работать только тогда, когда у датастора есть затык по производительности, и он не справляется с обработкой всех операций ввода-вывода.
Если же мы посмотрим на SIOC v2, который появился в VMware vSphere 6.5 в дополнение к первой версии, то увидим, что теперь это часть SPBM, и выделение ресурсов работает на уровне виртуальных машин, а не датасторов. SIOC v2 использует механизм vSphere APIs for I/O Filtering (VAIO), который получает прямой доступ к потоку ввода-вывода конкретной ВМ, вне зависимости от того, на каком хранилище она находится.
Таким образом, вы можете использовать SIOC v2 для регулирования потребления машиной ресурсов хранилища в любой момент, а не только в ситуации недостатка ресурсов.
Поэтому важно понимать, что SIOC v1 и SIOC v2 можно использовать одновременно, так как они касаются разных аспектов обработки потока ввода-вывода от виртуальных машин к хранилищам и обратно.
SIOC v2 включается в разделе политик SPBM, в секции Host-based rules:
На вкладке Storage I/O Control можно выбрать предопределенный шаблон выделения ресурсов I/O, либо кастомно задать его:
Для выбранной политики можно установить кастомные значения limit, reservation и shares. Если говорить о предопределенных шаблонах, то вот так они выглядят для варианта Low:
Так для Normal:
А так для High:
Если выберите вариант Custom, то дефолтно там будут такие значения:
Лимит можно задать, например, для тестовых машин, где ведется разработка, резервирование - когда вы точно знаете, какое минимальное число IOPS нужно приложению для работы, а shares можете регулировать долями от 1000. Например, если у вас 5 машин, то вы можете распределить shares как 300, 200, 100, 100 и 100. Это значит, что первая машина будет выжимать в три раза больше IOPS, чем последняя.
Еще один плюс такого назначения параметров SIOC на уровне ВМ - это возможность определить политики для отдельных дисков VMDK, на которых может происходить работа с данными разной степени интенсивности:
После того, как вы настроили политики SIOC v2, вы можете увидеть все текущие назначения в разделе Monitor -> Resource Allocation -> Storage:
Мы часто пишем о томах VVols (Virtual Volumes), которые позволяют вынести часть нагрузки по обработке операций с хранилищами на сторону аппаратных устройств (они, конечно же, должны поддерживать эту технологию), что дает пользователям преимущества по сравнению с VMFS. В инфраструктуре VVols массив сам определяет, каким образом решать задачи доступа и организации работы с данными для виртуальных машин, выделяя для их объектов (виртуальные диски и прочее) отдельные логические тома (VVols).
Один из известных производителей, поддерживающих технологию VVols - это компания Pure Storage. Недавно Cody Hosterman написал статью о том, как подключить тома VVols в VMware vSphere через PowerCLI для хранилищ Pure Storage. Коди развивает свой модуль PowerShell, который называется PureStorage.FlashArray.VMware.
Давайте посмотрим, как он работает. Сначала можно почитать о доступных опциях командлета Mount-PfaVvolDatastore, с помощью которого можно сделать монтирование датастора VVol:
Командлет может делать следующее:
Проверяет, презентован ли protocol endpoint (PE) указанного массива кластеру. Если нет, то с его помощью можно сделать это.
Ресканирует кластер, чтобы убедиться, что PE виден хостам.
Монтирует VVol в кластере.
Возвращает датастор хранилищу.
Пример 1 - имеется прямой доступ к массиву
Соединяемся с vCenter и создаем соединение с FlashArray:
Значит тут мы полагаем, что администратор хранилищ уже настроил PE, и вам нужно только смонтировать том VVol:
Так как датастор VVol ранее не монтировался, нельзя просто создать array connection (нет доступа к массиву). В этом случае подойдет командлет Get-VasaStorageArray:
Передав в командлет монтирования массив FA-m50, имя кластера и имя датастора, можно смонтировать том VVol:
На днях компания VMware объявила о том, что теперь ее продукты можно будет попробовать в рамках проекта VMware Odyssey, который доступен как дополнение к лабораторным работам Hands-On Labs (HOL). Odyssey - это 15-минутные задачки, которые добавляют элемент геймификации в скучный процесс выполнения лаб.
VMware провела эксперимент с геймификацией в реальном мире на vForum Singapore 2018 - там 52 участника сформировали команды по 2-3 человека, создав 18 команд, которые выполняли задачи на сообразительность и скорость:
В рамках этого мероприятия правильность решения задач проверялась персоналом HoL вручную, но спустя 6 месяцев, компания VMware сделала свой движок геймификации, который обрабатывает полученные пользователем конфигурации автоматически.
Проект Odyssey был создан в рамках инфраструктуры Hands-on Labs, где мануалы были несколько изменены таким образом, чтобы протестировать знания участников в рамках ограниченного времени. Как только пользователь выполняет задание - он получает мгновенную обратную связь о правильности его выполнения.
Есть также лидерборд, где участники в командах по всему миру могут посоревноваться в выполнении задачек на время:
Многим администраторам знакома такая вещь: сначала для теста устанавливается виртуальная машина VMware vCenter Server Appliance в конфигурации tiny (минимальные аппаратные настройки), а потом она приживается, и хочется сделать из нее полноценную производственную среду управления (конфигурацию large). Только вот не хочется ее переустанавливать.
Для тех, кто столкнулся с такой проблемой, Robert Szymczak написал полезный пост о том, как это сделать (но помните, что это неофициальная и неподдерживаемая процедура).
Установщик vCSA использует фреймворк Electron, настраивая конфигурацию через JSON, и механизм JSON-Schema для установки и валидации параметров. Поэтому в ISO-образе вы сможете найти конфигурацию сервера vCenter по следующему пути:
Там как раз и находятся данные о типовых конфигурациях vCSA. Например, так выглядит размер xlarge:
"xlarge": {
"cpu": 24,
"memory": 49152,
"host-count": 2000,
"vm-count": 35000,
"disk-swap": "50GB",
"disk-core": "100GB",
"disk-log": "25GB",
"disk-db": "50GB",
"disk-dblog": "25GB",
"disk-seat": "500GB",
"disk-netdump": "10GB",
"disk-autodeploy": "25GB",
"disk-imagebuilder": "25GB",
"disk-updatemgr": "100GB",
"disk-archive": "200GB",
"required-disk-space": "1180GB",
"label": "X-Large vCenter Server with Embedded PSC",
"description": "This will deploy a X-Large VM configured with 24 vCPUs and 48 GB of memory and requires 1180 GB of disk space will be updated for xlarge later. This option contains vCenter Server with an embedded Platform Services Controller for managing up to 2000 hosts and 35,000 VMs."
}
Таким образом вы поймете, на какие именно конфигурации нужно изменить компоненты виртуальной машины с vCenter. Перед изменением конфигурации сделайте снапшот машины vCSA, который сохранит параметры ее виртуального аппаратного обеспечения.
Теперь переходим, собственно, к изменению самой конфигурации:
1. Увеличение CPU и памяти (RAM).
Остановите машину.
Хорошая идея - вывести ее ESXi-хост из кластера DRS.
Зайдите на ESXi через Host Client, после чего в настройках ВМ измените конфигурацию CPU и памяти, чтобы выставить ее в соответствии с нужной конфигурацией.
2. Увеличение диска ВМ с сервером vCSA.
Об увеличении дискового пространства сервера vCSA 6.5 мы писали вот в этой статье. С тех пор ничего особо не изменилось. Некоторую дополнительную информацию вы также можете получить в KB 2145603 на случай если что изменится в процедуре vCSA 6.x.
Диски нужно настраивать не только по размеру, но и по корректной позиции в виртуальном слоте SCSI.
Примерно так это выглядит для vCenter 6.7 Update 2:
Назначение
Позиция в фале JSON
Номер VMDK
Слот SCSI
root / boot
n/a
1
0:0
tmp
n/a
2
0:1
swap
1
3
0:2
core
2
4
0:3
log
3
5
0:4
db
4
6
0:5
dblog
5
7
0:6
seat
6
8
0:8
netdump
7
9
0:9
autodeploy
8
10
0:10
imagebuilder
9
11
0:11
updatemgr
10
12
0:12
archive
11
13
0:13
Помните, что иногда имя VMDK может не соответствовать его позиции в слоте SCSI. Например, встречаются случаи, когда VMDK0 смонтирован в слот SCSI(0:4), а VMDK2 - в слот SCSI(0:0). В этом случае реальным загрузочным диском будет VMDK2, а не VMDK0, несмотря на их названия.
Также обратите внимание, что SCSI слот 0:7 не используется - не ошибитесь.
После изменения этих параметров запустите vCenter и убедитесь, что все в порядке.
Напомним, что Helpdesk Utility предназначена для сотрудников технической поддержки, работающих с пользователями инфраструктуры виртуальных ПК. Она реализует всю функциональность Helpdesk в HTML5 интерфейсе управления VMware Horizon.
Давайте посмотрим, что нового в Horizon Helpdesk Utility 1.4 (о прошлой версии мы писали вот тут):
Добавлена предварительная поддержка Horizon 7.9.
Больше не требуется наличие лицензии Helpdesk.
Возможность взаимодействия с машинами vCenter.
Возможность открывать консоли машин vCenter.
Возможность выполнять пакетные действия с виртуальными машинами.
Возможность запускать задачи refresh / recompose прямо из утилиты.
Добавлен механизм опроса (polling), чтобы получить время операций логина, если при запросе сессии не произошло возврата данных.
Убрана графика со страницы логина, которая доставляла неприятные ощущения.
Убраны пустые пункты при выборе Pod из меню в трее.
Исправлены проблемы с производительностью при нескольких открытых окнах.
Исправлена ошибка с падением, когда нельзя было получить время операции логина.
Исправлена ошибка с падением при завершении процессов.
Исправлены проблемы с делегированием административных функций.
Улучшено поведение при изменении темы.
Устранены утечки памяти при нахождении приложения в трее.
Скачать Horizon Helpdesk Utility 1.4 можно по этой ссылке.
А вот что нового появилось в Horizon Toolbox 7.8.1 (о версии 7.2 мы писали еще в 2017 году):
Поддержка Horizon View 7.5, 7.6, 7.7, 7.8 (да, до версии 7.9 еще не добрались, но, наверное, уже совсем скоро добавят).
Исправлено множество ошибок.
Напомним, что Horizon Toolbox - это расширение возможностей Horizon View, которое позволяет получать информацию о виртуальных ПК, производительности и сессиях пользователей в инфраструктуре VMware Horizon View.
На днях VMware сделала анонс о завершении M&A-сделки по приобретению компании Avi Networks, которая занимается разработкой программного обеспечения в сетевой сфере, способствующего прозрачной доставке пользователям приложений в онпремизных и облачных датацентрах.
Цель приобретения - дополнить портфолио продукта NSX технологиями, которые позволяют создать multicloud network-virtualization overlay (NVO) на уровнях 2-7 в рамках законченной концепции SDN (software-defined networks).
Философия Avi Networks заключается в том, что частные облака должны оперировать с приложениями точно так же, как и публичные, обеспечивая переносимость машин и приложений между датацентрами вне зависимости от исходной ИТ-инфраструктуры каждого из них.
Основные фичи, которые предоставляет Avi Networks для облачных инфраструктур:
Глобальный балансировщик для серверов на уровне датацентров
Ускорение миграции и работы приложений
Обеспечение защиты приложений при их миграции между облаками
Обеспечение доступности приложений
Мониторинг производительности и отчетность
Обнаружение сервисов в датацентре
Контейнеризация приложений на сетевом уровне (для миграции между датацентрами)
Предоставление RESTful API для интеграции в существующую сетевую инфраструктуру датацентров
Некоторые компоненты Avi Networks, в частности балансировщик нагрузки, будут интегрированы в продукт VMware NSX, также само решение Avi Networks будет доступно как самостоятельный ADC-продукт для глобальной балансировки нагрузки, сетевого экранирования (Web application firewall, WAF) и расширенной аналитики и отчетности о сетевой инфраструктуре приложений датацентров.
Например, можно получить вот такой отчет об end-to-end коммуникации пользователей с приложением, визуализирующий время отклика на каждом из сетевых сегментов:
Более подробнее о приобретении Avi Networks можно узнать из этого поста в блоге VMware.
Это гостевой пост нашего спонсора - сервис-провайдера ИТ-ГРАД, предоставляющего услугу аренды виртуальных машин из облака. В MIT предложили систему, которая в два раза уменьшит объем электричества, потребляемого «твердотельниками» в ЦОД. Рассказываем, как она устроена.
Проблема энергопотребления
Приблизительно через десять лет на вычислительные системы (в целом) будет приходиться40% потребляемой электроэнергии. За пятую часть этого объема будут «ответственны» центры обработки данных.
Системы хранения данных — один из основных «потребителей» электроэнергии в ЦОД. Чтобы сократить расходы на содержание СХД, операторы дата-центров заменяют жесткие диски на твердотельные накопители. Последние более производительны и энергоэффективны: известны случаи, когда SSD уменьшали объем потребляемого стойками СХД электричества на 60%.
Но ситуация все равно далека от идеальной. В машинном зале крупного дата-центра могут находиться сотни стоек с накопителями, и счета за электроэнергию остаются большими. Поэтому сегодня разрабатываются новые технологии, чтобы еще сильнее сократить энергопотребление SSD. Одну из таких технологий представили в MIT. Специалисты вуза спроектировали архитектуру системы хранения данных на базе твердотельных накопителей, которая снижает расходы операторов ЦОД на электричество в два раза. Ее назвали LightStore.
Как устроена система
LightStore представляет собой хранилище типа «ключ — значение» (KV-хранилище). Ключом считаются пользовательские запросы к СХД, а значением — сами данные. Систему разворачивают на специальном аппаратном узле в сети ЦОД. Его подключают напрямую, в обход серверов хранения данных (дополнительно потребляющих электроэнергию).
Узел построен на базе энергоэффективного CPU, а также NAND- и DRAM-памяти. Управляет им контроллер и специализированное ПО. Первый компонент отвечает за обмен данными с массивами NAND, а второй — за хранение ключей и их обработку. В основе программной архитектуры LightStore лежат так называемые LSM-деревья — структуры данных, используемые во всех современных СУБД.
Кластер LightStore масштабируется линейно путем подключения дополнительных узлов к сети. Для этих целей применяются специальные адаптеры. Они формализуют пользовательские запросы к СХД и трансформируют их в понятные для нее команды. Обработка запросов производится с использованием согласованного хеширования — при добавлении новой пары ключ-значение, хеш рассчитывается только для нее, а не для всех пар. Аналогичный подход применяют системы Redis и Swift.
В общем случае архитектуру LightStore и схему ее подключений в ЦОД можно представить вот так:
По словам разработчиков, пропускная способность LightStore при работе в 10GbE-сети дата-центра превышает 600 Мбит/с. При этом один ее узел потребляет на 10 Вт меньше, чем узел «классических» SSD-систем — для них этот показатель равен 20 Вт. Также оборудование занимает в два раза меньше места, отчасти из-за того, что LightStore не требуются серверы хранения.
Сейчас инженеры из MIT занимаются исправлением недостатков LightStore и расширением функциональности системы. Например, ее «учат» работать с атомарными запросами и запросами по диапазону. Также в планах разработчиков добавить поддержку SQL-запросов. Авторы убеждены, что в будущем LightStore может стать отраслевым стандартом для SSD-хранилищ в центрах обработки данных.
Аналоги решения
В прошлом году компания Marvell, которая занимается разработкой СХД, анонсировала SSD-контроллеры с интеллектуальными функциями. Они построены на базе систем ИИ, которые оптимизируют энергопотребление SSD в ЦОД. Ожидается, что решение найдет применение в машинных залах организаций, занимающихся аналитикой больших данных.
Еще один пример — накопитель WD Blue SSD с повышенной производительностью и энергоэффективностью. Устройство использует спецификацию NVMe для подключения дисков к шине PCI Express. Такой подход позволил повысить эффективность накопителя при работе с большим числом параллельных запросов. Устройство имеет скорость чтения в 545 МБ/с и скорость записи в 525 МБ/с. NVMe может стать стандартом ИТ-индустрии для SSD-интерфейсов. Производителям аппаратного обеспечения больше не придется расходовать ресурсы на разработку уникальных драйверов и разъемов.
В будущем можно ожидать появления большего числа решений, повышающих энергоэффективность СХД, подобных системам из MIT, Marvell и WD.
Напомним, что данное средство предназначено для записи пользовательских сессий и активности в виртуальных десктопах и приложениях, доставляемых по протоколу Blast Extreme. С помощью Session Recording администратор Horizon имеет возможность перенаправить запись экрана сессий пользователей, сделанных в определенное время, на центральный сервер, где потом он может воспроизвести их в HTML5-консоли. Саму сессию в виде видеофайла можно скачать как MP4 для воспроизведения в локальном плеере.
Добавлена поддержка версии VMware Horizon 7.8 и более поздних, включая только что вышедшую 7.9.
Добавлена возможность записи на базе членства пользователей в группах.
Множество багов было исправлено в агенте для виртуального десктопа.
Некоторые ошибки были также пофикшены на сервере.
Скачать VMware Horizon Session Recording можно по этой ссылке. Кстати, вместе с утилитой идет подробный документ с картинками, объясняющий аспекты развертывания и настройки продукта. Вы можете скачать его, выбрав нужный элемент в комбо-боксе:
RSS
