Гостевой пост нашего партнера - сервис-провайдера ИТ-ГРАД, предоставляющего услуги аренды виртуальных машин.

Итак, вы решили воспользоваться услугой аренды облачной инфраструктуры в формате IaaS, получили доступ в облако. Что дальше? Как подключиться к облачной площадке, с каких шагов начать в первую очередь, зачем нужен vCloud Director, как он устроен и для каких задач используется? Ответы на эти и другие вопросы дадим в этой статье.

Прежде чем перейти к выполнению практических действий, предлагаем взглянуть на то, из каких элементов состоит облачная инфраструктура провайдера. Подобно кирпичикам, из которых строится здание, в основе облачной инфраструктуры на базе VMware лежит правильное железо, технология виртуализации vSphere и vCloud Director.

При этом vCloud Director представляет собой ключевой объект облака и именно к нему заказчик получает доступ. Наделенный удобным и гибким интерфейсом, vCloud Director используется для развертывания виртуальных машин, контейнеров, шаблонов и предлагает дополнительные возможности, в том числе касающиеся управления внутриоблачными сетями.

Окно авторизации vCloud Director

Чтобы попасть в панель vCloud Director, необходимо пройти по прямой ссылке, предоставленной провайдером. Хотя нередки случаи, когда ссылка на vCloud Director размещается на главной странице личного кабинета пользователя. В любом случае, обратившись к vCD, необходимо авторизоваться, для чего в окне авторизации вводится предоставленный поставщиком услуг логин и пароль. В дальнейшем пароль рекомендуется изменить.

Базовые элементы vCloud Director

После успешной авторизации открывается Home page или главная страница vCloud Director, в которой создаются объекты инфраструктуры. При этом важно понимать, с какими элементами vCloud Director вы будете работать и для каких целей они используются. Остановимся на самых важных...Читать статью далее ->>

Часто администраторы виртуальной инфраструктуры VMware vSphere испытывают необходимость увеличить размер виртуального диска VMDK, который защищен технологией репликации VMware vSphere Replication. Если попытаться увеличить диск из vSphere Client, то вы получите вот такую ошибку:

vSphere Replication does not support changing the length of a replicated disk

Поэтому для увеличения реплицируемого VMDK-диска нужно сделать следующее:

• Переименуйте папку с виртуальной машиной и виртуальным диском на резервном сайте. Это нужно для того, чтобы при отключении репликации папка с ВМ на резервной площадке не удалилась.
• Запомните настройки репликации ВМ (RPO, датастор назначения и т.п.).
• Отключите репликацию виртуальной машины.
• Увеличьте размер виртуального диска на основной площадке из GUI vSphere Web Client через Edit Settings.
• Теперь увеличьте размер виртуального диска на резервной площадке с помощью утилиты vmkfstools. Для этого выполните команду:

vmkfstools –X 50G virtual_machine.vmdk

• Далее на резервном сайте переименуйте папку с ВМ обратно к исходному имени.
• Настройте репликацию ВМ заново, выбрав пункт Specify datastore folder и указав папку с ВМ, которую будете реплицировать. Появится сообщение:

A file with the name ‘[<datastore>] <folder>/<filename> already exists. Press Yes to use file as an initial copy.

• Нажимайте Yes и репликация должна завестись.

Если вы не увеличите размер виртуального диска на резервной площадке, то получите вот такое сообщение об ошибке:

The capacity of the seed disk does not match the capacity of the replication source disk. Create a new seed copy or verify that you selected the correct seed to use for this replication

Поэтому не пропускайте этот шаг. Также о процедуре написано в KB 2052883.

Недавно мы писали о полезных утилитах командной строки виртуального модуля VMware vCenter Server Appliance (vCSA), которые могут пригодиться при ежедневном администрировании виртуальной инфраструктуры VMware vSphere. А сегодня поговорим о сервисах vCSA - как они запускаются, и как ими управлять.

Первичный порядок загрузки служб vCenter Server Appliance выглядит следующим образом (приведены в порядке запуска):

• lwsmd (Likewise Service Manager)
• vmafdd (VMware Authentication Framework)
• vmdird (VMware Directory Service)
• vmcad (VMware Certificate Service)
• vmware-sts-idmd (VMware Identity Management Service)
• vmware-stsd (VMware Security Token Service)
• vmdnsd (VMware Domain Name Service)
• vmware-psc-client (VMware Platform Services Controller Client)
• vmon (VMware Service Lifecycle Manager)

А где же такие службы, как vmware-vpostgres, vpxd и прочие? Все просто - их запускает служба vmon. Это новый watchdog-сервис, который управляет службами vCSA в vSphere 6.5 и унифицирует доступ к ним через API.

Чтобы увидеть, в каком порядке она запускает прочие сервисы, выполним команды vmon-cli для остановки и запуска служб vmon на сервере vCSA:

/usr/lib/vmware-vmon/vmon-cli --batchstop ALL 

/usr/lib/vmware-vmon/vmon-cli --batchstart ALL

Вывод будет примерно таким:

root@vc01 [ /var/log/vmware/vmon ]# grep "Executing op START on service" vmon-sys 

17-12-12T09:44:23.639142+00:00 notice vmon Executing op START on service eam... 

17-12-12T09:44:23.643113+00:00 notice vmon Executing op START on service cis-license... 

17-12-12T09:44:23.643619+00:00 notice vmon Executing op START on service rhttpproxy... 

17-12-12T09:44:23.644161+00:00 notice vmon Executing op START on service vmonapi... 

17-12-12T09:44:23.644704+00:00 notice vmon Executing op START on service statsmonitor... 

17-12-12T09:44:23.645413+00:00 notice vmon Executing op START on service applmgmt... 

17-12-12T09:44:26.076456+00:00 notice vmon Executing op START on service sca... 

17-12-12T09:44:26.139508+00:00 notice vmon Executing op START on service vsphere-client... 

17-12-12T09:44:26.199049+00:00 notice vmon Executing op START on service cm... 

17-12-12T09:44:26.199579+00:00 notice vmon Executing op START on service vsphere-ui... 

17-12-12T09:44:26.200095+00:00 notice vmon Executing op START on service vmware-vpostgres... 

17-12-12T09:45:33.427357+00:00 notice vmon Executing op START on service vpxd-svcs... 

17-12-12T09:45:33.431203+00:00 notice vmon Executing op START on service vapi-endpoint... 

17-12-12T09:46:54.874107+00:00 notice vmon Executing op START on service vpxd... 

17-12-12T09:47:28.148275+00:00 notice vmon Executing op START on service sps... 

17-12-12T09:47:28.169502+00:00 notice vmon Executing op START on service content-library... 

17-12-12T09:47:28.176130+00:00 notice vmon Executing op START on service vsm... 

17-12-12T09:47:28.195833+00:00 notice vmon Executing op START on service updatemgr... 

17-12-12T09:47:28.206981+00:00 notice vmon Executing op START on service pschealth... 

17-12-12T09:47:28.220975+00:00 notice vmon Executing op START on service vsan-health...

Как мы видим, службы запускаются в следующем порядке:

• eam (VMware ESX Agent Manager)
• cis-license (VMware License Service)
• rhttpproxy (VMware HTTP Reverse Proxy)
• vmonapi
• statsmonitor
• applmgmt
• sca (VMware Service Control Agent)
• vsphere-client
• cm
• vsphere-ui
• vmware-vpostgres (VMware Postgres)
• vpxd-svcs
• vapi-endpoint
• vpxd (VMware vCenter Server)
• sps (VMware vSphere Profile-Driven Storage Service)
• content-library
• vsm
• updatemgr
• pschealth
• vsan-health

Утилиту vmon-cli можно использовать для запуска и остановки этих сервисов в следующем формате:

/usr/lib/vmware-vmon/vmon-cli -r ServiceName

Например, чтобы перезагрузить vSphere Client, можно использовать команду:

/usr/lib/vmware-vmon/vmon-cli -r vsphere-client

Известный своими скриптами блоггер Luc Dekens (LucD) опубликовал интересный сценарий PowerCLI для виртуальной инфраструктуры VMware vSphere, который позволяет вычистить права доступа на объекты, для которых уже существуют права на уровне родительских объектов.

Например, у вас есть такая картина:

Соответственно, нам нужно почистить пермиссии в папке Test1131 для пользователя Local\test, чтобы разрешения остались только на уровне родительского объекта Test1 (там, как мы видим, установлена опция применения разрешений вниз к дочерним объектам).

Собственно, сам скрипт:

<#
.SYNOPSIS
  Find and remove redundant permissions on vSphere objects 
.DESCRIPTION
  The function will recursively scan the permissions on the
  inventory objects passed via the Entity parameter.
  Redundant permissions will be removed.
.NOTES
  Author:  Luc Dekens
.PARAMETER Entity
  One or more vSphere inventory objects from where the scan
  shall start
.EXAMPLE
  PS> Optimize-Permission -Entity Folder1 -WhatIf
.EXAMPLE
  PS> Optimize-Permission -Entity Folder?
.EXAMPLE
  PS> Get-Folder -Name Folder* | Optimize-Permission
#>
 
  [cmdletbinding(SupportsShouldProcess=$true)]
  param(
    [parameter(ValueFromPipeline)]
    [PSObject[]]$Entity
  )
 
  Begin{
    function Optimize-iVIPermission{
      [cmdletbinding(SupportsShouldProcess=$true)]
      param(
        [parameter(ValueFromPipeline)]
        [VMware.Vim.ManagedObjectReference]$Entity,
        [VMware.Vim.Permission[]]$Permission = $null
      )
 
      Process{
        $entityObj = Get-View -Id $Entity
        $removePermission = @()
        $newParentPermission = @()
        if($Permission){
          foreach($currentPermission in $entityObj.Permission){
            foreach($parentPermission in $Permission){
              if($parentPermission.Principal -eq $currentPermission.Principal -and
                 $parentPermission.RoleId -eq $currentPermission.RoleId){
                $removePermission += $currentPermission
                break
              }
              else{
                $newParentPermission += $currentPermission
              }
            }
          }
        }
        else{
          $newParentPermission += $entityObj.Permission
        }
        if($removePermission){
          if($pscmdlet.ShouldProcess("$($entityObj.Name)", "Cleaning up permissions")){
            $removePermission | %{
              $authMgr.RemoveEntityPermission($Entity,$_.Principal,$_.Group)
            }
          }
        }
        $Permission += $newParentPermission
       
        if($entityObj.ChildEntity){
            $entityObj.ChildEntity | Optimize-iVIPermission -Permission $Permission
        }
      }
    }
  }
 
  Process{
    foreach($entry in $Entity){
       if($entry -is [System.String]){
        $entry = Get-Inventory -Name $entry
       }
       Optimize-iVIPermission -Entity $entry.ExtensionData.MoRef
    }
  }
}

Скрипт работает так, что пробегается по дереву объектов, обнаруживает избыточные разрешения и удаляет их. У скрипта есть удобный параметр WhatIf, который выводит операции по очистке разрешений, которые как бы применяются к дочерним объектам, но на самом деле не применяет их:

Optimize-VIPermission -Entity Test1 -WhatIf

Результатом будет список объектов, где разрешения будут очищены, в данном случае, если посмотреть на пример выше, это будет папка Test1131:

Можно запустить скрипт и на 2 папки сразу:

Optimize-VIPermission -Entity Test1,Test2 -WhatIf

Результат будет таким (в папке Test22 также есть дублирующиеся разрешения):

Также можно использовать и конструкции с масками, например:

Get-Folder -Name Test? | Optimize-VIPermission -WhatIf

Теперь неплохо было бы, если бы кто-то написал GUI к этой штуке, а также добавил туда функции поиска и удаления произвольных разрешений в выбранных объектах.

Недавно мы писали о том, что такое и как работает механизм отказоустойчивости VMware vCenter Server Appliance High Availability (vCHA), защищающий виртуальные модули vCenter Server Appliance (vCSA) в случае программных и аппаратных сбоев.

Там мы рассказывали, что vCHA - это Active/Passive кластер, который состоит из трех компонентов - активного узла, работающего под нагрузкой, пассивного, готового взять на себя нагрузку в случае сбоя активного, а также компонента Witness ("свидетель") - который защищает кластер от ситуации split-brain (оба узла считают себя активными в случае изоляции сети) и является кворумным узлом:

Напомним, что кворумный узел не может получить роль сервера vCenter, это лишь маленькая машина, реализующую функцию Witness в ситуациях изоляции и разделения сети.

Если посмотреть на архитектуру решения, то можно понять, что оно не использует сеть хранения для сигналов доступности и не рассчитано на множественные сбои, что позволит гарантированно сохранить или восстановить работоспособность только в случае отказа/изоляции лишь одного из компонентов. Если, например, вся сеть развалится между всеми тремя узлами - vCHA вас не спасет.

С точки зрения синхронизации, кластер vCHA использует синхронную репликацию PostgreSQL native replication для синхронизации базы данных (в случае отказа БД будет консистентная) и утилиту rsync для репликации файлов vCenter (например, файлов конфигурации):

Поэтому надо понимать, что теоретически некоторые файлы при сбое можно будет потерять, так как репликация асинхронная (но это, в целом, маловероятно).

Оба узла vCSA в кластере vCHA используют один публичный IP-адрес, который используется при доступе и к резервному узлу в случае сбоя основного. В условия восстановления работоспособности сервера vCSA заложен показатель RTO=5 минут. Это значит, что в случае сбоя основного узла, где-то 5 минут пользователи могут испытывать проблемы с доступностью vCenter через vSphere Client или vSphere Web Client. При этом API vCenter будет доступен уже где-то через 2-3 минуты.

Теперь давайте посмотрим, как обрабатываются механизмом vCHA различные варианты отказов:

• Отказ активного узла. В этом случае пассивный узел видит, что активный узел больше недоступен, при этом узел Witness работает и доступен. Пассивный узел назначает себя активным и начинает обслуживать запросы клиентов vSphere.
• Отказ пассивного узла. Поскольку активный узел и Witness чувствуют себя нормально, сервер vCenter продолжит обслуживание клиентов.
• Отказ узла Witness. В этом случае сохранится статус кво - активный узел продолжит обрабатывать запросы, а пассивный будет готов взять на себя нагрузку в случае сбоя активного.
• Изоляция или отказ более чем одного узла. В этом случае вполне может возникнуть ситуация, когда у вас сервисы vCenter не функционируют - например, оба узла vCSA могут посчитать себя изолированными (см. далее).

Поведение изолированного узла vCSA при изоляции

Как только узел себя считает изолированным, он сразу гасит все сервисы vCenter, чтобы второй узел мог взять на себя нагрузку по обслуживанию запросов (при этом неважно, видит ли второй узел компонент Witness). При детектировании события изоляции учитываются возможные короткие промежутки в доступности сети, которые могут иногда возникать при нормальном сетевом взаимодействии. Только когда все попытки достучаться до второго узла и Witness исчерпаны, узел vCSA считает себя изолированным.

Ну и, напоследок, порекомендуем документ "vCenter Server 6.5 High Availability Performance and Best Practices", о котором мы писали вот тут.

Как знают администраторы VMware vSphere, с выходом каждой новой версии платформы увеличиваются и максимумы для ее компонентов. Многие из этих максимумов трудно достижимы на практике, поскольку еще нет серверов такой возможности (например, для запуска такого количества машин в производственной среде), но некоторые аспекты требуют того, чтобы лимиты параметров были увеличены (например, число vNIC на одну машину иногда для тестирования нужно больше).

Давайте взглянем на эволюцию максимумов VMware vSphere в таблицах ниже, где отображены параметры версии 5.5, 6.0 и 6.5:

Максимумы виртуальных машин

Максимумы вычислительных мощностей VMware ESXi

Максимумы хранилищ VMware ESXi

Максимумы сетевого взаимодействия VMware ESXi

Мы часто пишем о виртуальном модуле VMware vCenter Server Appliance (vCSA), который представляет собой готовую виртуальную машину для управления виртуальной инфраструктурой VMware vSphere (напомним, что это полноценная замена vCenter for Windows).

Сегодня мы покажем несколько интересных утилит командной строки vCSA, которые могут помочь вам в ежедневной эксплуатации этого управляющего сервиса.

1. Просмотр журнала Cron.

vCSA имел раньше проблемы со сжатием фалов журнала (логов), что приводило к тому, что дисковые разделы быстро заполнялись. Поэтому следующей командой можно посмотреть, когда в последний раз выполнялись запланированные задачи Cron:

ls -l /var/spool/cron/lastrun/

Для сравнения ниже приведен вывод этой команды совместно с выводом текущей даты:

vc:~ # date

Mon Dec 4 12:55:39 CET 2017

vc:~ # ls -l /var/spool/cron/lastrun/

total 0

-rw------- 1 root root 0 Dec 3 20:00 cron.daily

-rw------- 1 root root 0 Dec 4 12:15 cron.hourly

-rw------- 1 root root 0 Dec 1 20:00 cron.weekly

Как мы видим, крон успешно выполнялся для ежечасной задачи, ежедневной и еженедельной. Если же крон отвалился, то значит, скорее всего, устарел пароль root. Узнать это можно следующей командой:

grep "Authentication token is no longer valid; new one required" /var/log/messages.0.log | head

Если в выводе этой команды будет что-то вроде этого:

<timestamp> vcenter /usr/sbin/cron[<ID>]: Authentication token is no longer valid; new one required

значит пароль root устарел.

2. Смена устаревшего пароля root.

Если ваш пароль root устарел, и крон-таски vCSA не запускаются, то сменить его проще всего будет следующей командой (обратите внимание, что это НЕ слово change):

chage -l root

У вас запросят старый пароль и попросят задать новый:

Password change requested. Choose a new password.

Old Password:

New password:

После этого можно снова вывести срок действия пароля с помощью chage (тут видно, что он устареет через 99999 дней, то есть 274 года):

vc:~ # chage -l root

Minimum: 0

Maximum: 99999

Warning: 7

Inactive: -1

Last Change: Dec 27, 2016

Password Expires: Never

Password Inactive: Never

Account Expires: Never

3. Перезапуск служб vCSA.

Если вы хотите поправить странное поведение vCSA, которое может быть связано с некорректным поведением сервисов Linux внутри виртуального модуля, то можно перезапустить все службы:

service-control --stop --all

service-control --start --all

Можно перезапустить, например, только vSphere Client:

service-control --stop vsphere-client

Список запущенных служб узнается так:

service-control --list

А вот так узнается статус того или иного сервиса:

service-control --status

4. Работа с LVM

Если вам надо увеличить виртуальные диски VMDK, а потом расширить тома LVM, то можете прочитать вот эту нашу статью. Чтобы не использовать API Explorer или PowerCLI, можно выполнить следующую команду для просмотра томов LVM:

lsblk

Далее вы получите примерно следующее:

vc:~ # lsblk

NAME MAJ:MIN RM SIZE RO MOUNTPOINT

sda 8:0 0 20G 0

??sda1 8:1 0 132M 0 /boot

??sda2 8:2 0 1G 0 [SWAP]

??sda3 8:3 0 10.9G 0 /

sdb 8:16 0 1.4G 0

sdc 8:32 0 25G 0

??swap_vg-swap1 (dm-8) 253:8 0 25G 0 [SWAP]

sdd 8:48 0 50G 0

??core_vg-core (dm-7) 253:7 0 50G 0 /storage/core

sde 8:64 0 10G 0

??log_vg-log (dm-6) 253:6 0 10G 0 /storage/log

sdf 8:80 0 10G 0

??db_vg-db (dm-5) 253:5 0 10G 0 /storage/db

sdg 8:96 0 5G 0

??dblog_vg-dblog (dm-4) 253:4 0 5G 0 /storage/dblog

sdh 8:112 0 25G 0

??seat_vg-seat (dm-3) 253:3 0 25G 0 /storage/seat

sdi 8:128 0 1G 0

??netdump_vg-netdump (dm-2) 253:2 0 1016M 0 /storage/netdump

sdj 8:144 0 10G 0

??autodeploy_vg-autodeploy (dm-1) 253:1 0 10G 0 /storage/autodeploy

sdk 8:160 0 10G 0

??invsvc_vg-invsvc (dm-0) 253:0 0 10G 0 /storage/invsvc

fd0 2:0 1 4K 0

sr0 11:0 1 1024M 0

Для идентификации дисковых устройств и их типов можно выполнить следующее:

lsscsi

Вывод будет примерно таков:

vc:~ # lsscsi

[0:0:0:0] disk VMware Virtual disk 1.0 /dev/sda

[0:0:1:0] disk VMware Virtual disk 1.0 /dev/sdb

[0:0:2:0] disk VMware Virtual disk 1.0 /dev/sdc

[0:0:3:0] disk VMware Virtual disk 1.0 /dev/sdd

[0:0:4:0] disk VMware Virtual disk 1.0 /dev/sde

[0:0:5:0] disk VMware Virtual disk 1.0 /dev/sdf

[0:0:6:0] disk VMware Virtual disk 1.0 /dev/sdg

[0:0:8:0] disk VMware Virtual disk 1.0 /dev/sdh

[0:0:10:0] disk VMware Virtual disk 1.0 /dev/sdi

[0:0:12:0] disk VMware Virtual disk 1.0 /dev/sdj

[0:0:14:0] disk VMware Virtual disk 1.0 /dev/sdk

[1:0:0:0] cd/dvd NECVMWar VMware IDE CDR00 1.00 /dev/sr0

Когда вы поймете, какой том нужно увеличить, выполните команду:

vpxd_servicecfg storage lvm autogrow

Надо помнить, что это сработает только для томов под управлением LVM (например, для disk 1 (sda) с разделом / - не сработает).

5. Поиск "загрязняющих" файлов.

Чтобы найти логи, которые могут засорить корневой раздел или раздел /storage/log, выполните одну из следующих команд:

du -a /var | sort -n -r | head -n 10
du -a /storage/log | sort -n -r | head -n 10

6. Изменение режима ротации логов (Log Rotation).

Сначала перейдем в папку с логами:

cd /etc/logrotate.d

Далее сделаем бэкап настроек:

cp dnsmasq ./dnsmasq.old

Затем откроем настройки:

vi dnsmasq

И поменяем слово "weekly" (еженедельно) на "daily" (ежедневно), например:

/var/log/dnsmasq.log {

daily

missingok

notifempty

delaycompress

sharedscripts

postrotate

[ ! -f /var/run/dnsmasq.pid ] || kill -USR2 cat /var/run/dnsmasq.pid

endscript

create 0640 dnsmasq dnsmasq

После этого можно удалить старый большой лог следующими командами:

cd /var/log

rm dnsmasq.log

7. Удаление файлов, которые не удалились.

Бывает так, что вы удалили большой файл, а дисковое пространство не высвободилось - и это видно командой df -h. Это происходит потому, что какой-то из процессов в памяти еще держит файл (при этом не обязательно использует его). Чтобы узнать, что это за процесс выполняем команду:

lsof | grep deleted

Вывод будет примерно таким:

postgres 8860 vpostgres 10u REG 253,4 16777216 16395 /storage/dblog/vpostgres/pg_xlog/000000010000011900000041 (deleted)

Видим, что это Postgres держит файл, поэтому если он нам сейчас не нужен, убиваем процесс:

kill -9 <PID>

После этого вы увидите, что свободного дискового пространства на сервере vCSA стало больше.

С начала ноября мы не писали про тонкий клиент на базе HTML5 для управления виртуальной инфраструктурой - VMware vSphere Client (тогда он был версии 3.27). На днях компания VMware выпустила его версию 3.30, поэтому давайте рассмотрим новые возможности, которые появились в последних трех версиях клиента - VMware vSphere Client 3.28-3.30.

Итак, что нового:

• Просмотр имеющихся лицензий (Host/Cluster/функции Solutions) - пока работает в режиме Read-Only.
• Доступны детали лицензированных продуктов и их фичей.
• Детали лицензий сервера vCenter и хостов ESXi (Host License) - доступно в разделе Configure > Licensing.
• Проверки состояния vSphere Distributed Switch (vDS health checks).
• Настройка фильтрации трафика и правил его маркировки на уровне распределенных порт-групп.
• Экспорт и импорт распределенных виртуальных коммутаторов (vDS) и распределенных порт-групп.
• Настройка политик распределенных порт-групп внутри мастера создания новой порт-группы.
• Настройка CPU Identification Mask в разделе Advanced.
• Выбор паравиртуализованного сетевого адаптера PVRDMA для сети виртуальных машин.

Скачать последнюю версию VMware vSphere Client 3.30 можно по этой ссылке.

Cormac Hogan написал занимательный пост о об использовании дискового пространства в кластере VMware vSAN. Всех интересует - умеет ли vSAN возвращать дисковое пространство хранилищу при удалении файлов в гостевой ОС виртуальной машины? Ответ - пока нет, но над этим работают.

Cormac провел вот какой эксперимент: взял виртуальную машину в кластере vSAN с гостевой ОС Windows Server 2012 R2, у которой было 386.7 ГБ занятого места (сама ВМ была развернута на тонких дисках):

Затем он скопировал туда данные на 800 МБ, после чего увидел, что занятое место увеличилось до 388.37 ГБ, то есть выросло на 1,6 ГБ. Это логично, так как vSAN работал в режиме RAID-1 (зеркалированные VMDK-диски):

Далее он удалил только что скопированные файлы и убедился, что занятое дисковое пространство осталось тем же самым (то есть, в vSAN нет поддержки UNMAP/TRIM изнутри гостевой системы):

Между тем, он снова скопировал те же 800 МБ и к радости администраторов заметил, что дисковое пространство увеличилось лишь на 20 МБ (в совокупности на 40 МБ с учетом RAID-1).

То есть занятые после прошлого копирования блоки были использованы повторно:

Такая штука есть у Windows Server, но у Linux в файловой системе ext4 такой трюк не прокатит - все равно при повторном копировании блоки разместятся в другом месте, и пространство будет использовано повторно. Но это особенность файловой системы ext4, об этом подробно написано тут и тут. Для ФС ext3 и XFS это не актуально, там блоки тоже будут переиспользоваться.

Ну и помните, что описанное применимо только для удаления файлов изнутри гостевой ОС, если же вы удалите на хранилище vSAN виртуальную машину или другой объект - пространство сразу же вернется в общий пул хранения.

Недавно компания VMware опубликовала интересный документ, описывающий референсную архитектуру решения для виртуализации и доставки виртуальных ПК и приложений - "Horizon 7 Enterprise Edition Multi-Site Reference Architecture". Он предназначен для тех Enteprise-администраторов, которые планируют построение распределенной VDI-инфраструктуры для VDI-пользователей на базе двух географически разделенных площадок.

Цель подобных документов (Reference Architecture) - показать на высоком уровне возможные сферы применения продукта для построения указанной архитектуры (в данном случае - отказо и катастрофоустойчивости), а также валидировать ее дизайн и соответствие его решаемым задачам.

Вот какие кейсы раскрываются и сравниваются в документе:

С точки зрения рассматриваемых архитектур, в документе приводятся следующие варианты использования:

1. Архитектура Active/Active и Active/Passive для сервисов.

Тут Windows-сервис пользователю доставляется в виде терминальной сессии на RDS-хосте, либо через виртуальную машину, которая реплицируется на другой хост. Приложения, которые развертываются в ВМ в виде подключаемых виртуальных дисков App Volumes, также реплицируются. Опционально настраивается также репликация профилей пользователей и их данных.

В этом случае пользователи могут получить доступ к своим данным и приложениями через любую площадку, которая ему географически ближе:

А вот так выглядит в этом случае архитектура Active/Passive, которая берет на себя нагрузку только с случае отказа основной площадки:

2. Архитектура Active/Active и Active/Passive для приложений через App Volumes.

В этом случае можно использовать хосты RDS и подключать к ним тома App Volumes напрямую с приложениями при загрузке серверов, либо при логине пользователей. Пользователь может использовать свои приложения при соединении с любой площадкой:

А так выглядит отказоустойчивая архитектура Active/Passive для AppVolumes:

3. Архитектура Active/Active для профилей пользователей.

В этом случае можно обеспечить отказо и катастрофоустойчивость данных пользователей и их профилей при использовании доставляемых через RDSH-сервисы приложений.

Также возможно настроить инфраструктуру таким образом, чтобы на резервной площадке, например, пользователи получали ограниченную функциональность реплицируемых профилей.

4. Резервирование рабочего пространства Workspace ONE.

Workspace ONE - это веб-портал, через который пользователь корпоративной ИТ-инфраструктуры посредством SSO получает доступ к своим приложениям. Здесь используется решение VMware Identity Manager и репликация баз данных этого продукта средствами SQL AlwaysOn:

Ну и главное, что рассматриваются все аспекты переключения VDI-инфраструктуры на резервную площадку в контексте хранилищ, сетей и серверов:

Ну а все технические подробности и детали настройки конфигураций приведены в интересном 136-страничном документе.

Некоторое время назад мы писали о том, как делать резервное копирование и восстановление базы данных сервера vCenter Server и виртуального модуля vCenter Server Appliance (vCSA). А сегодня мы поговорим о том, как сделать бэкап всей виртуальной машины vCSA с помощью средств PowerCLI.

Для начала напомним, что простейший способ бэкапить сервер vCSA - это сделать его резервную копию в графическом интерфейсе на вкладке Summary:

Но если вам нужно резервное копирование и восстановление с помощью сценариев PowerCLI, то для этого можно использовать функцию Backup-VCSAToFile, о которой Brian Graf рассказывал вот тут. Бэкап может проводиться в следующие хранилища назначения:

• FTP
• FTPS
• HTTP
• HTTPS
• SCP

Для управления процессом резервного копирования можно использовать следующие функции:

• Backup-VCSAToFile
• Get-VCSABackupJobs
• Get-VCSABackupStatus

Отрабатывает Backup-VCSAToFile следующим образом:

Некто Magnus Andersson на базе функции Backup-VCSAToFile создал вот такой скрипт попроще, который позволяет забэкапить сервер vCSA, задав в заголовке сценария несколько параметров:

• Сервер бэкапов и директория
• Имя пользователя и пароль на хранилище назначения
• Тип бэкапа - Fullbackup (полный) или Seatbackup (только конфигурация vCSA)
• Пароль к файлу бэкапа, который понадобится при восстановлении
• Тип хранилища бэкапа
• Комментарий

Пользоваться скриптом просто, вот он:

# Script to backup vCenter Server Appliance
# Author: Magnus Andersson - Sr Staff Solutions Engineer @Nutanix
# Version 1.0
# Created 2017-11-15
# Kudos to Brian Graf for creating the Backup-VCSAToFile function, used in this script, which can be found here Backup-VCSAToFile Function Created By Brian Graf - https://www.brianjgraf.com/2016/11/18/vsphere-6-5-automate-vcsa-backup/
#
#--------------------------------------------
# User Defined Variables Sections Starts Here
#
# Specify vCenter Server, vCenter Server User name and vCenter Server Password
$vcsa="vcsa01.vcdx56.local"
$vcsauser="vcsabkpuser@vsphere.local"
$vcsapasswd="TopSecret76!"
# 
# Backup location
$bkpserver="10.10.100.199/vcsabackups/"
$bkpdir=get-date -uformat %Y-%m-%d
$bkpLocation=$bkpserver+$bkpdir
#
# Specify backup location user and password
$LocationUser="ftps-user"
$LocationPasswd="TopSecret67!"
#
# Specify backup type where Fullbackup is 1 and Seatbackup is 2
$BackupType=2
#
# Specify backup password - needed when performing restore
$bkpPassword="TopSecret68!"
#
# Specify backup localtion type where you must specify HTTP, HTTPS, SCP, FTP or FTPS
$LocationType="FTPS"
#
# Specify Backup Comment
$Comment="vCenter Server Appliance vcsa01.vcdx56.local backup"
#
# User Defined Variables Sections Ends Here
#--------------------------------------------
#
# Import Module VMware.VimAutomation.Cis.Core
Import-module VMware.VimAutomation.Cis.Core
#
# #--------------------------------------------
# Import Backup-VCSAToFile Function
Function Backup-VCSAToFile {
    param (
        [Parameter(ParameterSetName=’FullBackup’)]
        [switch]$FullBackup,
        [Parameter(ParameterSetName=’SeatBackup’)]
        [switch]$SeatBackup,
        [ValidateSet('FTPS', 'HTTP', 'SCP', 'HTTPS', 'FTP')]
        $LocationType = "FTP",
        $Location,
        $LocationUser,
        [VMware.VimAutomation.Cis.Core.Types.V1.Secret]$LocationPassword,
        [VMware.VimAutomation.Cis.Core.Types.V1.Secret]$BackupPassword,
        $Comment = "Backup job",
        [switch]$ShowProgress
    )
    Begin {
        if (!($global:DefaultCisServers)){ 
            [System.Windows.Forms.MessageBox]::Show("It appears you have not created a connection to the CisServer. You will now be prompted to enter your vCenter credentials to continue" , "Connect to CisServer") | out-null
            $Connection = Connect-CisServer $global:DefaultVIServer 
        } else {
            $Connection = $global:DefaultCisServers
        }
        if ($FullBackup) {$parts = @("common","seat")}
        if ($SeatBackup) {$parts = @("seat")}
    }
    Process{
        $BackupAPI = Get-CisService com.vmware.appliance.recovery.backup.job
        $CreateSpec = $BackupAPI.Help.create.piece.CreateExample()
        $CreateSpec.parts = $parts
        $CreateSpec.backup_password = $BackupPassword
        $CreateSpec.location_type = $LocationType
        $CreateSpec.location = $Location
        $CreateSpec.location_user = $LocationUser
        $CreateSpec.location_password = $LocationPassword
        $CreateSpec.comment = $Comment
        try {
            $BackupJob = $BackupAPI.create($CreateSpec)
        }
        catch {
            Write-Error $Error[0].exception.Message
        }
            

        If ($ShowProgress){
            do {
                $BackupAPI.get("$($BackupJob.ID)") | select id, progress, state
                $progress = ($BackupAPI.get("$($BackupJob.ID)").progress)
                Write-Progress -Activity "Backing up VCSA"  -Status $BackupAPI.get("$($BackupJob.ID)").state -PercentComplete ($BackupAPI.get("$($BackupJob.ID)").progress) -CurrentOperation "$progress% Complete"
                start-sleep -seconds 5
            } until ($BackupAPI.get("$($BackupJob.ID)").progress -eq 100 -or $BackupAPI.get("$($BackupJob.ID)").state -ne "INPROGRESS")

            $BackupAPI.get("$($BackupJob.ID)") | select id, progress, state
        } 
        Else {
            $BackupJob | select id, progress, state
        }
    }
    End {}
}
#
#--------------------------------------------
# Create passwords
[VMware.VimAutomation.Cis.Core.Types.V1.Secret]$BackupPassword=$bkpPassword
[VMware.VimAutomation.Cis.Core.Types.V1.Secret]$LocationPassword=$LocationPasswd
#
# Connect to vCenter Server Appliance
Connect-CisServer -Server $vcsa -User $vcsauser -Password $vcsapasswd 
#
# Start the backup
If ($BackupType -eq 1) {
	Backup-VCSAToFile -BackupPassword $BackupPassword -LocationType $LocationType -Location $bkpLocation -LocationUser $LocationUser -LocationPassword $locationPassword -Comment $Comment -Fulbackup ShowProgress
	}
	Else {
	Backup-VCSAToFile -BackupPassword $BackupPassword -LocationType $LocationType -Location $bkpLocation -LocationUser $LocationUser -LocationPassword $locationPassword -Comment $Comment -Seatbackup -ShowProgress
	}
#
# Disconnect from vCenter Server Appliance
disconnect-CisServer $vcsa -confirm:$false
#

Надо сказать, что для скрипта нужно использовать пользователя, определенного на уровне SSO, так как если вы возьмете пользователя из AD, но с правами группы SSO Administrators - сценарий все равно работать не будет.

Скачать сценарий можно с репозитория на GitHub по этой ссылке.

Восстановить бэкап vCSA можно через vCenter Server Appliance Installer, выбрав опцию Restore:

Не секрет, что в небольших организациях администраторы виртуальной инфраструктуры также зачастую являются и сетевыми администраторами. Это значит, что они обязаны знать не только устройство виртуальных сетей, но и должны управлять физической сетевой инфраструктурой, которая часто построена на оборудовании Cisco.

Специально для таких администраторов, активист Neil Anderson выпустил руководство по лабораторным работам на 350 страницах (!), которое поможет сдать экзамены на сертификацию Cisco CCNA (Cisco Certified Network Associate). В частности, в нем раскрываются детали лаб последних версий экзаменов 200-125 CCNA, 100-105 ICND и 200-105 ICND.

Содержимое документа по разделам (в целом, это самые нужные азы, что будет полезно и тем, кто экзамен сдавать не планирует):

• The IOS Operating System
• The Life of a Packet
• The Cisco Troubleshooting Methodology
• Cisco Router and Switch Basics
• Cisco Device Management
• Routing Fundamentals
• Dynamic Routing Protocols
• Connectivity Troubleshooting
• RIP Routing Information Protocol
• EIGRP Enhanced Interior Gateway Routing Protocol
• OSPF Open Shortest Path First
• VLANs and Inter-VLAN Routing
• DHCP Dynamic Host Configuration Protocol
• HSRP Hot Standby Router Protocol
• STP Spanning Tree Protocol
• EtherChannel
• Port Security
• ACL Access Control Lists
• NAT Network Address Translation
• IPv6 Addressing
• IPv6 Routing
• WAN Wide Area Networks
• BGP Border Gateway Protocol
• Cisco Device Security
• Network Device Management 

Скачать документ можно по этой ссылке: Free CCNA Lab Guide. Штука-то очень нужная для тех, кто сдает на CCNA, так что качайте.

Те из вас, кто следит за новостями VMware, знают, что некоторое время назад компания отказалась от развития своего публичного облака (ранее оно называлось vCloud Air и было продано в OVH) в пользу партнерских решений на стороне облаков сервис-провайдеров. Главным и первым из таких партнеров стала компания Amazon, которая совместно с VMware предлагает IaaS-услугу аренды виртуальных машин на базе AWS.

В мае этого года случилось невероятное: два заклятых конкурента - VMware и Microsoft - предложили совместную услугу VMware Horizon Cloud on Microsoft Azure, позволяющую получить в аренду виртуальные десктопы и приложения.

Но главная новость пришла в конце ноября - теперь две компании, жестко борящиеся за рынок серверной виртуализации, будут давать в аренду серверы VMware vSphere на оборудовании облака Azure.

Как оказалось, VMware не очень-то довольна этим фактом, но рынок есть рынок - VMware проиграла войну за публичные облака и теперь IaaS-сервисы VMware будет предлагать в том числе Microsoft.

Пока технология находится в стадии технологического превью, но есть уже первые новости от Microsoft. Вкратце они заключаются в следующем:

• Microsoft предоставит средства миграции рабочих нагрузок частного облака в инфраструктуру VMware в облаке Azure. Эти средства позволят вам обнаружить виртуальные машины VMware vSphere и связи между ними (как показано на картинке выше), а потом смигрировать их на платформу Azure. При этом заранее будут посчитаны требуемые ресурсы и, главное, примерная стоимость месячной аренды ресурсов Azure. Решение Azure Site Recovery (ASR) позволит обеспечить правильный порядок миграции и минимальное время простоя. Azure Database Migration Service позволит перенести БД SQL Server и Oracle на PaaS-платформу Azure SQL Database.
• Microsoft обеспечит интеграцию сервисов Azure и VMware. Это включает в себя такие решения, как Azure Backup, Azure Site Recovery (для Disaster Recovery-решений), управление апдейтами и конфигурациями, Azure Security Center и средства аналитики Azure Log Analytics. Кроме этого, можно будет управлять инфраструктурой и средствами VMware - с помощью консоли vRealize Automation.
• Microsoft будет развивать средства эксплуатации гибридных облаков. Это позволит создать единую гибридную инфраструктуру между онпремизным облаком VMware vSphere и виртуальными машинами на платформе Azure. Заявляется, что ВМ в облаке будут запущены на оборудовании датацентров Microsoft и ее партнеров (про загадочных партнеров очень интересно написано тут), но на серверах ("на колокейшене") как bare-metal гипервизоры будет установлен полный стек решений VMware vSphere.

Такие дела, Microsoft победила:) Несколько полезных ресурсов на почитать:

• Azure Migration Center - там утилиты, документ и описания технологий миграции, в том числе от партнеров, таких как Turbonomic, Movere и Cloudamize.
• Дополнительная информация о сценариях миграции с VMware на Azure.
• Бесплатный курс Azure for VMware vSphere Admins.

Пока идет обкатка технологического превью, а полностью сервисы VMware из облака на платформе Azure будут доступны в 2018 году.

Мы часто пишем о встроенной утилите на хосте ESXi - esxtop, которая позволяет отслеживать все основные аспекты производительности хост-серверов и виртуальных машин (процессор, память, диски и сеть). Напомним, что наши последние посты о esxtop расположены тут, тут, тут, тут, тут и тут.

А недавно вышло весьма полезное образовательное видео "Using esxtop to Troubleshoot Performance Problems", в котором показано на практическом примере, как именно использовать esxtop для решения проблем производительности (хотя голос и весьма уныл):

Ну и напомним, что у esxtop есть графический интерфейс - это утилита VisualEsxtop.

Довольно давно мы уже рассказывали о механизме применения политик для хранилищ при развертывании виртуальных машин - VMware vSphere Storage Policy Based Management (SPBM). А недавно Кормак Хоган опубликовал интересную заметку, касающуюся возможности выбора политик SPBM конкретным пользователем во время развертывания новой виртуальной машины.

Прежде всего, в vSphere нет механизма назначения прав доступа пользователей на конкретную политику SPBM - все пользователи видят все политики. Но сам механизм разграничения прав существует - его можно реализовать на уровне прав доступа к хранилищам.

Например, пользователю ben мы даем доступ Read-only к хранилищу VVols1, то есть создавать виртуальные машины он на нем не может:

А на хранилище VVols2 делаем его администратором:

В итоге, при развертываниии виртуальной машины пользователь ben видит оба хранилища - VVols1 и VVols2 и все доступные политики хранилищ (комбобокс VM storage policy):

Однако, обратите внимание, что при выборе хранилища VVols1 в разделе Compatibility написано о том, что пользователь не имеет достаточных привилегий, чтобы создать машину на этом датасторе.

You do not hold the privilege to allocate space on the selected datastore

Между тем, кнопка Next активна. Но если нажать ее, мастер все равно дальше не пустит:

Вверху мы увидим:

Specify a valid location

Ну а если выбрать VVols2, то все проверки пройдут успешно, и пользователь сможет там создать виртуальную машину:

Гостевой пост сервис-провайдера ИТ-ГРАД, предоставляющего виртуальные машины из облака IaaS в аренду.

В статье «Миграция в облако» мы рассказывали о частичном и полном переходе на облачную площадку, рассматривали примеры реальных кейсов, затрагивая наиболее распространенные ошибки. Сегодня поговорим о том, какие инструменты помогают мигрировать между различными облаками и когда возникает такая необходимость.

Зачем мигрировать

На практике нередки ситуации, когда требуется перенести виртуальные машины с одной площадки на другую, например из частного облака компании в публичное облако IaaS-провайдера. Это актуально и тогда, когда наблюдается мгновенная нехватка собственных ресурсов или клиент решает сменить поставщика облачных услуг. Миграция между облаками также может быть вызвана изменениями в законодательстве. К слову сказать, многие иностранные компании, осуществляющие деятельность на территории РФ, размещали собственные информационные системы, а с ними и персональные данные россиян на зарубежных облачных площадках. Но с выходом ФЗ-152 «О защите персональных данных» потребовалась миграция в облака российских поставщиков.

Так, известная во всем мире компания VBH («Фаубеха») — крупнейший дистрибьютор товаров и услуг для оконных, дверных производств — столкнулась с задачей внедрения нового на тот момент ERP-решения Microsoft Dynamics Axapta 2009. Компания размещала собственную инфраструктуру в облачном дата-центре на территории Германии. Используя единое облачное пространство, удалось создать стандартизированную инфраструктуру с такими ERP-решениями, как Microsoft Dynamics Navision, Axapta, 1С и SAP.

С выходом нового закона, который обязал хранить персональные данные на территории Российской Федерации, потребовалось перенести часть систем в Россию. Сервис в результате разместился на площадке российского облачного провайдера «ИТ-ГРАД». Об опыте подобных переездов расскажем ниже. Читать статью далее ->>

Бывает, что попытке развернуть виртуальную машину из шаблона (Template) вы получаете сообщение об ошибке "Customization of the guest operating system is not supported in this configuration":

Как правило, это происходит из-за того, что в машине не установлены VMware Tools. Просто сконвертируйте шаблон в ВМ, потом включите ее и установите тулзы, после чего конвертируйте машину опять в Template.

Также такая ситуация бывает, когда vCenter не поддерживает гостевую ОС виртуальной машины для кастомизации, либо когда развертывание происходит на NFS-хранилище, для которого не включена опция "no root squash".

С момента выхода последнего мажорного релиза платформы виртуализации VMware vSphere 6.5 мы много писали о шифровании виртуальных машин (и, кроме того, затрагивали тему производительности этого процесса), а также техниках шифрования кластеров vSAN (и некоторых особенностях этого). Сегодня мы поговорим о самом важном компоненте инфраструктуры шифрования vSphere - Key Management Service (KMS).

Прежде всего, KMS - это сервисы шифрования не только для виртуальных машин, но и любых других объектов ИТ-инфраструктуры. Поэтому KMS уже может быть в вашей организации, при этом он может не быть прикрученным к VMware vSphere. Вы можете использовать любой KMS-сервер, но VMware сертифицировала лишь следующие системы из списка (см. вот этот документ VMware):

Если же у вас другой KMS-провайдер, не расстраивайтесь - он, скорее всего, будет работать, если поддерживает протокол управления ключами KMIP 1.1.

Начать надо с вопросов доступности KMS-сервера. Как вы понимаете, это самый важный сервер в вашей инфраструктуре, важнее DNS или контроллера домена. Если у вас недоступен DNS, все тоже не работает, как и в случае с KMS, но если оказались недоступными данные хранилища KMS - это катастрофа для организации. И нет абсолютно никакого пути восстановить их. Совершенно никакого. Обо всем этом рассказывает видео ниже:

Таким образом, KMS становится бизнес-критичной точкой не только инфраструктуры, но и бизнеса в целом. И вопросы бэкапа и его доступности - это вопросы номер 1. Давайте посмотрим на несколько базовых понятий KMS:

• KMIP (Key Management Interoperability Protocol) - это стандарт, по которому клиент KMIP может общаться с серверами KMS. Каждый год он проходит серьезную проверку на конференции RSA.
• DEK (Data Encryption Key). Это ключ, который хост ESXi генерирует, когда требуется зашифровать виртуальную машину. Этот ключ используется также и для расшифровывания данных ВМ, он записан в VMX/VM Advanced settings в зашифрованном виде.
• KEK (Key Encryption Key). Это ключ, которым зашифрован DEK. KEK key ID также находится в VMX/VM Advanced settings.
• Key Manager Cluster/Alias - это коллекция адресов FQDN/IP всех реплицируемых между собой серверов KMS. Она также хранится вместе с зашифрованной машиной в VMX/VM Advanced settings, чтобы после ее включения можно было обратиться к нужному кластеру KMS, получить KEK для cервера vCenter, который разлочит ВМ.
• VM и vSAN encryption - это, на самом деле, с точки зрения реализации механизма шифрования одно и то же. То есть, для обоих типов шифрования используются одни и те же библиотеки, конфигурации и интерфейсы.

Когда мы говорим о кластере KMS - это всего лишь KMS-серверы, реплицирующие между собой хранилища ключей. Они не обеспечивают доступность друг друга, как, например, это делает VMware HA. Например, есть серверы KMS-A, KMS-B и KMS-C, в хранилищах которых при добавлении ключа новой ВМ он появляется мгновенно.

Если KMS-A недоступен как сервер, то сервер vCenter запрашивает ключи у хоста KMS-B. Если же KMS-A недоступен как сервис (то есть сервер работает, а служба KMS не отвечает), то vCenter ждет 60 секунд восстановления работоспособности сервиса и только потом переключается на KMS-B. Это поведение изменить нельзя.

Лучшие практики по использованию KMS таковы:

• По возможности нужно делегировать обязанности по поддержке инфраструктуры KMS отдельной команде (Security Team) или человеку.
• Не класть KMS-серверы в виртуальной машине в тот же кластер (например, vSAN), который также зашифрован. Иначе коробочка закроется (выключится кластер), а ключ от нее останется внутри нее же. То есть, необходимо держать хотя бы один из KMS-серверов за пределами такого домена отказа.
• Предыдущий пункт относится и к серверам vCenter и PSC. Чтобы они могли расшифровать другие сервера, они должны быть доступны в случае сбоя.

Теперь надо сказать о катастрофоустойчивости серверов KMS. Типичный кластер в рамках одной площадки выглядит так:

Но если на этой площадке будет авария, которая затронет все 3 сервера - бизнесу может настать конец. Поэтому в идеале надо использовать конфигурацию с двумя площадками:

Понятное дело, что у малого и среднего бизнеса резервных площадок, как правило, нет. В этом случае помочь может публичное облако Amazon AWS или Microsoft Azure. Чтобы поддерживать там одну резервную машину, много денег не нужно.

Ну и если вы используете конфигурацию с несколькими площадками, то обязательно нужно учитывать в конфигурации порядок обращения к серверам KMS в рамках площадки. Если на первой площадке находятся сервера KMS-A, KMS-B и KMS-C, а на второй - KMS-D, KMS-E и KMS-F, то в первом случае порядок должен быть A,B,C,D,E,F, а во втором - D,E,F,A,B,C.

Если на второй площадке вы будете использовать конфигурацию аналогичную первой, сервер vCenter может ходить по серверам другой площадки, которая может быть недоступна, а только обойдя все ее серверы, начнет использовать локальные KMS.

Мы много пишем о технологии Virtual Volumes (VVols), которая сравнительно недавно появилась в платформе виртуализации VMware vSphere. Совсем недавно мы писали о том, что будет в следующих версиях VVols, а сегодня давайте посмотрим на текущее положение дел.

Eric Siebert написал интересный пост о том, сколько компаний использует VVols сейчас в производственно среде. На данный момент VVols применяется примерно у 2% клиентов VMware, что весьма и весьма мало. Связано это, в первую очередь, с ограничениями технологии и небольшим количеством партнеров ее поддерживающих.

Между тем, подвижки в этом направлении уже есть. Вот какие факторы будут способствовать развитию VVols в ближайшем будущем (Эрик считает, что более половины всех пользователей vSphere будут применять эту технологию):

• Все больше клиентов переходят с vSphere 5.5 на vSphere 6.x, где VVols полностью поддерживаются.
• В vSphere 6.5 поддерживается функциональность аппаратной репликации томов VVol, что является очень важной и нужной фичей.
• Партнеры расширяют поддержку этой технологии в своих новых массивах.
• Клиенты все больше узнают о технологии, в том числе через этот пост:)

Если посмотреть на статистику использования VVols администраторами vSphere в различных компаниях, то во времени она выглядит так:

В принципе, прогресс за этот период выглядит неплохо (особенно в категории 100+), но в абсолютном выражении это, все-таки, очень мало. Ну и вот небольшой августовский отчет IDC про данную технологию - "VVols Provides Powerful Application-Aware Management for vSphere Environments".

Пара интересных роликов, вышедших на днях:

Не так давно мы публиковали несколько интересных заметок о VMware Tools (раз, два, три, четыре), которые объясняют множество моментов, касающихся развертывания и эксплуатации данного пакета, предназначенного для улучшения работы гостевых ОС в среде виртуализации VMware vSphere.

В этой заметке мы постараемся обобщить эти вещи и добавить еще несколько фактов о VMware Tools, которые должен знать каждый администратор платформы ESXi:

• Пакет VMware Tools для основных гостевых ОС входит в состав ESXi, но остальные поставляются отдельно от дистрибутивов платформы, и их можно скачать отсюда.
• Чтобы узнать версии тулзов для ОС Windows и Linux, идущие вместе с дистрибутивом ESXi или патчем, загляните по этой ссылке https://packages.vmware.com/tools/versions (а мы писали об этом вот тут).
• Стандартные VMware Tools, которые подходят для большинства ОС Windows и Linux можно обновлять через VMware Update Manager (VUM). Они накатываются в виде VIB-пакетов под названием "tools-light".
• Традиционный подход к обновлению VMware Tools на множестве хостов VMware ESXi - это использовать общий репозиторий для VMware Update Manager, который накатывает обновления на серверы. Более современный подход - это использовать механизм Auto Deploy для развертывания stateless-хостов, которые забирают актуальные версии VMware Tools прямо из онлайн-репозитория VMware.
• Версии VMware Tools состоят из двух релизов - VMware Tools 10.1.x и VMware Tools 10.0.x (это два разных ISO-образа). Версия 10.1.x - это развивающаяся ветка для современных гостевых систем (сейчас актуальна 10.1.15), а 10.0.12 - замороженная, которая предназначена для устаревших ОС, которые уже не обновляются. То есть апгрейд с версии тулзов 10.0.9 происходит на 10.1. Подробнее об этом рассказано в KB 2015161.

• Почти все Linux-дистрибутивы идут с интегрированной версией Open VM Tools.
• ISO-файлы VMware Tools теперь идут с файлами контрольных сумм, по которым можно проверить соответствие пакетов на аутентичность их происхождения за счет сверки хэшей. Поэтому надо быть внимательным при распаковке составляющих пакета, и ничего оттуда не убирать.
• Для VMware Tools, начиная с версии 10.1, доступна подробная документация.
• Все новые версии VMware Tools обратно совместимы со всеми версиями VMware ESXi, которые моложе как минимум на одно поколение. В этом можно убедиться, посмотрев VMware Interoperability Matrix:

• Для Linux существует 3 вида VMware Tools (подробнее тут):
  • Operating System Specific Packages (OSP) - пакеты, которые размещены на сайте VMware (их можно скачать/обновить без аутентификации), содержащие в себе те же самые компоненты, которые находятся в ISO-образах, идущих с дистрибутивами VMware ESXi. Этот метод поставки VMware Tools для Linux уже несколько устарел и используется для старых гостевых ОС.
  • Open VM Tools (OVT) - это пакеты VMware Tools с открытым исходным кодом, которые встраиваются в большинство современных Linux-дистрибутивов. Соответственно, при установке такой гостевой ОС в виртуальной машине, пакет VMware Tools будет там уже установлен. Исходный код OVT доступен для всех желающих в репозитории на GitHub, но официально поддерживаются только те OVT, которые идут вместе с дистрибутивами Linux. Если вы скомпилировали их самостоятельно - учтите, поддержки от VMware не будет.
  • TAR Tools - они предоставляются VMware и устанавливаются через сценарий. Но VMware рекомендует использовать OVT.
• VMware Tools дают множество возможностей для виртуальной машины и гостевой ОС, обо всех них написано вот тут.
• Виртуальные машины с Windows используют паравиртуализованные драйвера хранилищ и сетевых адаптеров, что улучшает взаимодействие гостевой ОС и соответствующих ресурсов. Вот почему после обновления тулзов машина хочет перезагрузиться.
• Для унификации развертывания VMware Tools нужно настроить централизованный репозиторий и сконфигурировать хосты ESXi таким образом, чтобы они брали последние версии тулзов оттуда. Об этом мы подробно писали вот тут, также вкратце информация есть об этом здесь и здесь.

Если у вас есть еще интересные моменты на эту тему - пишите в каменты!

С момента выпуска прошлой версии VMware ESXi Embedded Host Client 1.23 прошло довольно много времени (аж три месяца), и вот на днях компания VMware выпустила обновление - Host Client 1.24 (спасибо Илье за новость). Напомним, что это решение позволяет управлять отдельными хостами VMware ESXi через веб-интерфейс, построенный на базе HTML5. Для управления всей инфраструктурой vSphere используется vSphere Client.

Посмотрим на новые возможности VMware ESXi Embedded Host Client 1.24:

• Пофикшена ошибка при развертывании образа OVF/OVA с дисками, привязанными к нескольким дисковым контроллерам.
• Корректная обработка адресов (проблемы race condition) при добавлении сетевого адаптера виртуальной машине.
• Возможность просматривать хранилища VVol из datastore browser.
• Решена проблема с таймаутом, когда клиент получает от хоста неизвестный тип хранилища.
• Решена проблем с автостартом ВМ.
• Теперь можно загружать VMDK-файлы типа Flat через datastore browser.
• Показ корректной строчки VMware Tools в свойствах VM summary.
• Паджинация в VM editor, когда ВМ имеет много дисков.
• Поддержка свойств OVF с предопределенными значениями и показ комбобоксов для них.
• Возможность изменения пермиссий пользователя root.
• Поддержка выбора зависимых PCI-устройств при включении режима проброса устройства (passthrough).
• Минорные исправления ошибок.

Напомним, что для установки Host Client используется команда (также его можно обновить прямо из клиента, используя пункт Update):

ssh root@<esx ip or hostname> esxcli software vib install -v <URL>

где <URL> - это локальный путь или веб-адрес VIB-пакета.

Загрузить ESXi Embedded Host Client 1.24 можно по этой ссылке (там же можно скачать и VMware Remote Console, выбрав ее из списка объектов загрузки).

Allan Kjaer написал интересный скрипт PowerCLI, который позволит определить, какие логические тома Windows находятся в виртуальных дисках VMDK машин на платформе vSphere. Как-то я сталкивался с такой проблемой, поэтому может быть она не такая уж и редкая.

Скрипт соединяется с управляющим сервером VMware vCenter, запрашивает учетные данные к гостевой ОС Windows, после чего строит отчет о том, на каких дисках VMDK какие разделы были обнаружены. Отчет включает в себя индекс диска Windows, букву диска и метку тома.

Вот так он выглядит:

"vmName      vmHardDiskDatastore vmHardDiskVmdk           vmHardDiskName windowsDiskIndex windowsDiskSerialNumber          vmHardDiskUuid                   windowsDeviceID    drives   volumes

  ------      ------------------- --------------          -------------- ---------------- -----------------------          --------------                   ---------------    ------   -------

test-vm     FC01                 test-vm/test-vm.vmdk       Hard disk 1                   0 6000c29c481f32e9763fe6d2d8dc8f7b 6000C29c481f32e9763fe6d2d8dc8f7b \\.\PHYSICALDRIVE0 C:

test-vm     FC01                 test-vm/test-vm_1.vmdk     Hard disk 2                   1 6000c297d1a7352ed5ee1b870023f57d 6000C297d1a7352ed5ee1b870023f57d \\.\PHYSICALDRIVE1 D:       Data

test-vm     FC03                 test-vm/test-vm.vmdk       Hard disk 3                   2 6000c290e36c2f3b641a56308551e998 6000C290e36c2f3b641a56308551e998 \\.\PHYSICALDRIVE2 {E:, F:} {New Volume, New Volume}

Скрипт не особо тестировался, поэтому запуская его, предварительно смотрите по коду, что именно он делает и как. Посмотреть данный PowerCLI-сценарий можно по этой ссылке.

Некоторое время назад мы писали про анонс решения Veeam Availability Console, которое представляет собой комплекс интегрированных средств для сервис-провайдеров и больших компаний, которые позволяют организовать инфраструктуру BaaS (Backup-as-a-Service) для гибридной среды предприятия (внутренние инфраструктуры + облачные). Ранее этот продукт был известен как Veeam Managed Backup Portal for Service Providers.

На днях Veeam объявила о доступности для загрузки Veeam Availability Console - эволюционировавшего бэкап-портала для IaaS-провайдеров. Давайте посмотрим на это бесплатное (да!) решение поближе.

У данного продукта 3 основных назначения:

• Предоставляет крупным предприятиям средства для организации защиты как виртуальных машин основного датацентра, так и облачных ресурсов, а также удаленных офисов и мобильных пользователей.
• Позволяет сервис-провайдерам предоставлять услуги по резервному копированию и репликации виртуальных машин для своих пользователей средствами единой консоли с возможностью разделения управления по клиентам.
• Дает возможность партнерам и реселлерам запустить собственный бизнес для своих клиентов по организации хранения их резервных копий на своих площадках (и управления этим процессом), что увеличит возможности для зарабатывания денег партнерами, а клиентам позволит не заботиться о резервном копировании совсем.

Если суммаризовать основные нововведения решения, то можно выделить следующие моменты:

• Простая установка - как в облаках сервис-провайдеров, так и на онпремизных площадках больших инфраструктур.
• Удаленное управление и мониторинг агентов резервного копирования.
• Удаленное обнаружение компонентов инфраструктуры и развертывание агентов с поддержкой Veeam Cloud Connect.
• Веб-портал с возможностью разделения на нескольких клиентов.
• Нативный биллинг.
• Интерфейс RESTful API.

Сейчас более 16 тысяч сервис-провайдеров используют решение Veeam Cloud Connect для организации резервного копирования в облако. Делается это через компонент Veeam Cloud Gateway, где для соединения используется один порт TCP/UDP 6180 (это дает возможность просто обслуживать фаервол), а само соединение защищено TLS с SSL-сертификатом.

Veeam Availability Console легко интегрируется с этой инфраструктурой, образуя единую систему. При добавлении сервис-провайдера можно отметить чекбокс, разрешающий ему управлять бэкап-инфраструктурой на стороне клиента:

После этого и клиент, и сервис-провайдер в консоли Veeam Availability Console смогут в реальном времени видеть статус задач резервного копирования и бэкап-инфраструктуры в целом:

Обратите внимание, что если вы доверили сервис-провайдеру управление бэкап-инфраструктурой, он сможет удаленно запускать и останавливать задачи резервного копирования и репликации, которые выполняются на вашей площадке. Также он сможет загружать и логи в целях траблшутинга. Также можно еще удаленно подключиться к интерфейсу командной строки Veeam Shell.

В Veeam Availability Console есть расширенный механизм отчетности, который оповещает о состоянии инфраструктуры: какие задачи были выполнены или завершились неудачно, какие машины защищены, а какие нет, а также вас заранее предупредят о заканчивающейся емкости дискового пространства.

Всего мониторится около 30 преднастроенных алармов, а отчет падает в почтовый ящик администратору:

Не так давно мы писали о выходе Veeam Agent for Microsoft Windows 2.0. Решение Veeam Availability Console позволяет удаленно обнаруживать Windows-серверы на площадке заказчика и устанавливать туда этих агентов в целях резервного копирования содержимого серверов. Поддержка агентов для Linux ожидается в ближайших релизах.

При поиске серверов из мастер агента можно использовать 3 опции - диапазон IP-адресов, каталог Active Directory и CSV-файл с именами компьютеров:

Также администраторы портала могут определять политики - что бэкапить, как часто и т.п. При этом политик может быть сколько угодно, а определять их можно как на уровне клиентов, так и на уровне экземпляров.

Veeam Availability Console поддерживает RESTful API и обмен данными в JSON-формате, что позволяет интегрироваться с существующими портальными и биллинг-системами. Но для тех, у кого нет единой системы биллинга, Veeam Availability Console предоставляет свою систему учета потребленных ресурсов и инвойсинга.

Все это красиво визуализуется:

Сами пользователи могут получать инвойсы из веб-портала или по электронной почте.

Что касается поддержки нескольких клиентов, здесь Veeam сделала шаг вперед. Каждый клиент может самостоятельно заходить на портал, контролировать задачи резервного копирования, а главное управлять ключом шифрования (а точнее дешифрования) - это очень важно при бэкапе ВМ в облако.

Интересно, что интерфейсы оптимизированы под тач-девайсы (то есть, можно смотреть портал со своего iPad'а):

Ну и последняя приятная новость - Veeam сделала утилиту миграции для текущих пользователей Veeam Managed Backup Portal на Veeam Availability Console. Это действительно здорово, другие производители таким не балуют:

Помимо Veeam Availability Console для сервис провайдеров, есть еще и Veeam Availability Console for the Enterprise - версия портала, который можно использовать внутри большой корпоративной инфраструктуры. И главное, что это тоже БЕСПЛАТНО!

Загрузить Veeam Availability Console можно прямо сейчас по этой ссылке.

Летом мы писали о калькуляторе для сайзинга хранилищ инфраструктуры VMware vSAN 6.2. С тех пор вышли новые версии vSAN 6.5 и vSAN 6.6.1, в которых было реализовано несколько новых возможностей, соответственно, обновился и калькулятор - его новая версия доступна по этой ссылке. Новая версия построена на базе документов VMware vSAN Design and Sizing Guide 6.5 и 6.6.1 (глава 10.2 Capacity Sizing Example II).

Калькулятор представляет собой Excel-таблицу, в которой есть поля для ввода исходных данных (черные - это аппаратные параметры инфраструктуры и данные по консолидации ВМ, синие и зеленые - остальные параметры). Ранее этот калькулятор представлял собой Excel-документ в облаке OneDrive, но теперь любой может скачать его.

В верхней части таблицы черным шрифтом обозначаются ресурсы, которые рассчитываются только для того, чтобы можно было исполнять виртуальные машины в кластере Virtual SAN, а красным шрифтом выделен тот объем ресурсов, который вам потребуется, чтобы обеспечить требуемый уровень избыточности и отказоустойчивости.

В левой области таблицы данные параметры рассчитываются для All-Flash архитектуры кластера Virtual SAN, а правая часть предназначена для расчетов гибридной архитектуры (обычные HDD-диски для данных, а SSD-носители - для кэша).

Более подробно о калькуляторе написано вот тут.

Это гостевой пост сервис-провайдера ИТ-ГРАД, предоставляющего виртуальные машины в аренду.

Системы хранения данных, являясь основой стабильного функционирования любого предприятия, должны соответствовать параметрам доступности, надежности, безопасности и удовлетворять потребности бизнеса компании. Благодаря таким важным характеристикам СХД, как унифицированность, производительность и масштабируемость, затраты на них сегодня занимают одно из центральных мест в бюджете и составляют в среднем 20–25 % всех расходов. В этой статье мы рассмотрим решения NetApp как наилучшей системы хранения данных для современной компании.

NetApp: более 20 лет инноваций

Для начала предлагаем вспомнить, как развивалась NetApp в исторической перспективе, уделив внимание наиболее значимым моментам.

1992 г. Компания вводит в индустрию систем хранения данных абсолютно новые технологии, представляющие в совокупности законченное решение по хранению данных Network Appliance. На тот момент это была всего лишь файловая шара для Linux, куда позже добавили RAID 4, оптимизацию записи, организацию хранения данных WAFL, поддержку технологии Redirect on Wright (ROW), которая позволяет создавать снимки, не влияя на производительность. С тех пор линейка развивается эволюционно.

1995–1996 гг. Компания выпускает первый мультипротокольный сторадж, представляя технологию файлового доступа для Linux- и Windows-серверов с использованием протоколов SMB и NFS. А после реализует репликацию и поддержку файлового доступа поверх блочного, представляя унифицированную систему хранения данных. С тех пор NetApp пропагандирует консолидацию различных нагрузок на одну СХД и инвестирует в разработку технологий, повышающих эффективность хранения данных.

2007 г. NetApp анонсирует ключевое решение для гибкого клонирования и впервые представляет унифицированную дедупликацию, доступную для всех слоев хранения данных. Таким образом, продуктивный, архивный и медленный слой работают на блочный и файловый доступ. А следующим шагом стала кластеризация...Читать статью далее->>

Наш читатель Стас обратил внимание на то, что в начале ноября компания VMware выпустила значительное обновление для шестой версии платформы виртуализации VMware vSphere 6.0. Были опубликованы апдейты и патчи для ESXi 6.0 - ESXi600-201711001.

В составе гипервизора и прочих компонентов были обновлены следующие пакеты ESXi 6.0:

• VMware_bootbank_esx-base_6.0.0-3.79.6921384
• VMware_bootbank_vsan_6.0.0-3.79.6766495
• VMware_bootbank_vsanhealth_6.0.0-3000000.3.0.3.79.6769065
• VMware_bootbank_esx-dvfilter-generic-fastpath_6.0.0-3.79.6921384
• VMware_bootbank_misc-drivers_6.0.0-3.79.6921384
• VMware_bootbank_ipmi-ipmi-devintf_39.1-5vmw.600.3.79.6921384
• VMware_bootbank_ipmi-ipmi-msghandler_39.1-5vmw.600.3.79.6921384
• VMware_locker_tools-light_6.0.0-3.76.6856897

Обновления коснулись новых возможностей, подсистемы безопасности и исправлений наиболее серьезных ошибок. Чтобы скачать апдейт, нужно пойти на VMware Patch Portal, выбрать ESXi 6.0 и ввести там номер билда (6921384).

Правильно устанавливать обновление нужно следующими командами (если, конечно, на хосте есть интернет):

esxcli network firewall ruleset set -e true -r httpClient

esxcli software profile update -p ESXi-6.0.0-20171104001-standard -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

esxcli network firewall ruleset set -e false -r httpClient

Кроме того, на днях также было выпущено обновление VMware vCenter 6.0 Update 3c. Там появилось три основных новых улучшения:

• Включенная поддержка SMB2 для виртуального модуля vCenter Server Appliance 6.0 Update 3c, чтобы избежать уязвимости протокола SMB1.
• Совместимость с решениями VMware vSphere Replication 6.1.2.1 и VMware Site Recovery Manager 6.1.2.1.
• Улучшения кластеров VMware Storage DRS.

Получить больше информации об обновлении VMware vCenter 6.0 Update 3c можно по этим ссылкам:

• VMware-VIMPatch-6.0.0-7037384-20171101.iso
• VMware-vCenter-Server-Appliance-6.0.0.30300-7037817-patch-TP.iso
• VMware-vCenter-Server-Appliance-6.0.0.30300-7037817-patch-FP.iso

Скачать vCenter 6.0 u3c можно по этой ссылке.

Дункан написал интересный пост про работу кластера откзоустойчивых хранилищ VMware vSAN совместно с технологией отказоустойчивости хост-серверов VMware HA. Суть проблемы заключается в том, что кластер vSAN, как правило, организуется на базе обычной Ethernet-сети, которая не подразумевает наличие дополнительных хранилищ Heartbeat Datastores (на которых создаются специальные локи на файлы со стороны хостов).

А эти хранилища очень важны для кластеров VMware HA, так как по ним через сеть хранения данных (например, общие FC-хранилища) он определяет остались ли хосты работающими в случае отказа/разделения сети передачи данных, а также продолжают ли там работать виртуальные машины.

Если таких хранилищ в кластере vSAN нет (а их, скорее всего, нет), то могут возникнуть проблемы вот какого плана. В случае изоляции хоста (например, разделилась сеть или отказали порты коммутатора), сам кластер vSAN обрабатывает ситуацию корректно, но виртуальные машины продолжают быть запущены на изолированных хостах. В то же время, главная часть кластера HA (та, в которой остался Master) имеет копии этих же виртуальных машин и может запустить их, подумав, что они уже недоступны вместе с хостами, а это уже может привести к ситуации с дубликатами машин и их MAC/IP адресов, когда сеть восстановится.

Чтобы этого не происходило, на хостах ESXi нужно настроить реакцию на событие изоляции (isolation response). Хост декларирует себя изолированным при совместном наступлении двух событий:

• Он не получает коммуникации от хоста Master
• Он не может достучаться до isolation address

Если вы ничего не настраивали дополнительно в кластере HA, то ваш isolation address находится в Management network, которая и есть та сеть, в которой работает кластер vSAN (и которая, как мы помним, упала). И, на самом деле, это хорошо! Ведь если бы этот адрес продолжал быть доступен, то изолированная часть кластера не считала бы себя изолированной и случился бы split-brain с появлением возможных дубликатов машин.

Из этой всей ситуации можно сделать 3 вывода:

• Используйте отдельные от кластера vSAN хранилища Heartbeat Datastores, работающие в другой сети или по другим интерфейсам (если это возможно, конечно, в вашей инфраструктуре). Для этого нужно выбрать опцию "Use datastore from only the specified list" в настройках HA и добавить расширенную настройку "das.ignoreInsufficientHbDatastore = true" в advanced HA settings.
• Всегда ставьте действие isolation response в Power Off, чтобы машины выключились в случае изоляции хостов кластера HA, а главная часть кластера могла их перезапустить.
• Делайте isolation address в той же сети, что и основная сеть vSAN (интерфейсы VMkernel хостов), чтобы в случае изоляции хост ESXi считал себя изолированным, а не продолжающим нормально пинговать какой-то сторонний адрес. Для этого можно использовать Switch Virtual Interface (SVI) на физическом коммутаторе (если у вас немаршрутизируемая сеть vSAN).

Ну и напомним тут нашу подробную статью о совместном существовании vSAN и HA.

Автор известного технического блога о платформе VMware vSphere, Frank Denneman, совместно с одним из коллег выпустил весьма интересную книгу "vSphere 6.5 Host Resources Deep Dive".

В рамках 570-страничного талмуда авторы рассказывают все технические детали управления ресурсами на уровне хоста ESXi, такими как память, процессор, стек работы с хранилищами и сетевая архитектура. Довольно много содержимого книги посвящено архитектуре NUMA-узлов и оперативной памяти, механикам работы CPU и ядра VMkernel, а также прочим самым глубоким моментам программных и аппаратных компонентов хоста ESXi.

По уверению авторов книга покрывает, например, следующие технические вопросы:

• Оптимизация рабочих нагрузок для систем Non-Uniform Memory Access (NUMA).
• Объяснение того, как именно работает механика vSphere Balanced Power Management, чтобы получить преимущества функциональности CPU Turbo Boost.
• Как настроить компоненты VMkernel для оптимизации производительности трафика VXLAN и окружений NFV.

В общем, книга очень крутая и мудрая. Скачать ее можно по этой ссылке.

Иногда администратору решения по организации отказоустойчивых кластеров VMware vSAN требуется вывести отдельный хост VMware ESXi из кластера, после чего использовать его диски для организации томов VMware VMFS виртуальных машин уже не в рамках кластера.

Правильно делать это следующим образом.

1. Проверяем, является ли хост членом кластера vSAN:

esxcli vsan cluster get

2. Выводим хост ESXi из кластера:

esxcli vsan cluster leave

3. Убедимся, что хост вышел из кластера:

esxcli vsan cluster get

мы должны получить сообщение:

Virtual SAN Clustering is not enabled on this host

4. После этого надо очистить конфигурацию vSAN для дисков на хосте.

Для начала найдем все диски командой:

esxcli vsan storage list

далее идентифицируем диски vSAN, выполнив команду:

partedUtil getptbl <путь к устройству>

Здесь мы видим, что один из разделов еще видит себя частью vSAN. Сначала надо снять лок с диска, отключив автоуправление со стороны кластера vSAN (то есть, разрешаем ручные операции с хранилищами vSAN):

esxcli vsan storage automode set --enabled false

Если этого не сделать, мы получим такую ошибку:

Unable to remove device: Can not destroy disk group for SSD naa.6000c29c581358c23dcd2ca6284eec79 : storage auto claim mode is enabled

5. После этого можно окончательно вывести диск из кластера vSAN следующей командой:

esxcli vsan storage remove -s naa.50026b724712194a

здесь опция -s значит SSD-диск (так отключаются устройства кэширования), а если мы хотим вывести обычный диск, то вместо -s надо использовать опцию -d.

В середине октября мы писали о новых возможностях VMware vSphere Client версий 3.22-3.24. Напомним, что этот тонкий клиент на основе технологии HTML5 скоро заменит собой устаревающий Web Client на основе Adobe Flex. За последние 3 недели компания VMware успела выпустить целых три версии vSphere Client 3.25, 3.26 и 3.27.

Давайте посмотрим на новые возможности этих версий клиента:

• Всплывающее окно файлового менеджера Datastore File browser. Также была улучшена его производительность и информативность окна загрузки (показаны файлы в очереди и общий объем загружаемого контента).
• Добавление лицензии для хостов vSphere и возможность задания ее имени в рабочем процессе добавления. Также можно ее переименовывать и удалять.
• Просмотр свойств лицензий (лицензированных продуктов и технологий на хостах).
• Просмотр ассетов лицензии vCenter (в режиме read-only).
• Редактирование свойств и политик для распределенных портов vDS.
• Можно развернуть ВМ из шаблона, выбрав мастер создания новой ВМ, далее Deploy from template > вкладка Data center.
• Операция Rescan теперь выполняется параллельно на уровне датацентра и кластера.
• Группами Replication groups можно управлять через действие Edit VM Storage Policy.

Скачать VMware vSphere Client 3.27 можно по этой ссылке.