IP-HASH vs LBT

По ссылке подробно расписан режим балансировки нагрузки распределенного коммутатора.

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

Источник

Общие принципы CPU Scheduling

Что это такое и с чем его едят можно очень подробно почитать в исходном посте.

Углядел очень интересную мысль:

Распределение vCPU
CPU Scheduler распределяет vCPU между pCPU по принципу хорошего бутерброда с маслом. Что это значит? Это значит, что vCPU «размазываются» по как можно большему количеству pCPU ровным слоем. Без комков и дырок. Больше задействованных pCPU – больше кэша. Однако, такое поведение может не подойти под какую-нибудь конкретную задачу. Например, на виртуальной машине работает многопоточное приложение и его потоки активно взаимодействуют между собой. Преимущества общего кэша для такой ВМ очевидны. Осталось дать понять CPU Scheduler-у, что все vCPU этой ВМ было бы неплохо запускать на ядрах одного физического процессора. Намеки CPU Scheduler воспринимает при помощи параметров виртуальной машины. Параметр, отвечающий за консолидацию vCPU:
sched.cpu.vsmpConsolidate = true

Настройка статического MAC-адреса для VM

Иногда бывает необходимо задать статический MAC адрес для VM. Например при P2V миграции, когда лицензия приложения привязывается к MAC адресу.

С помощью VMware vSphere Client можно задать статический MAC, но только из диапазона 00:50:56:00:00:00 - 00:50:56:FF:FF:FF.

Изменить можно так же с помощью редактирования VMX-файла VM, при этом можно присвоить любой MAC-адрес.

Алгоритм:

1. Выключаем VM.

2. копируем vmx-файл на рабочую станцию.

3. Меняем значение ethernet0.addressType с “vpx” на “static”.

4. Меняем ethernet0.GeneratedAddress на ethernet0.Address и пишем нужный MAC:

ethernet0.address = "00:10:43:45:14:CC"

5. Включаем VM.

PS: иногда система не перечитывает vmx файл при запуске - как итог имеем случай, что VM оказывается со старым MAC-адресом.

Такой случай решается очень просто:

1. Выключаем VM

2. заходим в консоль ESXi по SSH.

3. Выполняем 2 команды:

vim-cmd vmsvc/getallvms |grep

Результат будет примерно таким:

32 SRVTST [Test] SRVTST/SRVTST.vmx rhel5Guest vmx-07 Test Server

32 - это Inventory ID виртуальной машины.

Перезагружаем файл VM:

vim-cmd vmsvc/reload 32

Переименование подключения Windows

Намного лучше, когда подключения на всех серверах называются одинаково, например все интерфейсы, подключенные в доменную сеть называть "Domain Network".

Как же это сделать на уже созданных серверах?

С помощью команды netsh.

netsh interface set interface name="Local Area Connection" newname="NewLan"

netsh может работать удаленно, а если речь о виртуальных серверах VMware, то данную команду можно выполнить на всех VM сразу:

Get-VM | Invoke-VMScript –ScriptText “netsh interface set interface name=""Local Area Connection"" newname="NewLan"” –ScriptType Bat –guestuser DomainAdmin –GuestPassword Password

Зачем нужна команда Netsh

Массовое переключение ВМ в другую портгруппу

Предположим, у вас меняется сетевая политика для виртуальных машин и вы создаете новые портгруппы. Или вы решили мигрировать на Distributed vSwitch. Соотв. есть много (поэтому вручную не вариант, или просто лень) ВМ, подключенных в одну портгруппу, и их надо переключить в другую.

Решение - PowerShell! :)

Как это сделал я для своего тестового кластера. Сначала создал Distributed vSwitch с одним аплинком (с каждого хоста) и на нем новую портгруппу для ВМ. Затем переключил пару включенных машин вручную, проверив, что они остались доступны. И оставшиеся N-цать выключенных переключил уже скриптом:

Get-Cluster "Cluster" | Get-VM | Where-Object {$_.PowerState -eq "PoweredOff"} | Get-NetworkAdapter | where { $_.Name -eq "Network Adapter 1" } | Set-NetworkAdapter -NetworkName "dv VM Network" -Confirm:$false

Скопипастил отсюда

Новые правила DRS в vSphere 4.1

В vSphere 4.1 при создании DRS правил появилась еще одна очень полезная опция, а именно VMs to Hosts affinity rules.

VMs to Hosts affinity rule-ы бывают двух видов:

• Must run rules (Принудительные) (а так же anti affinity)
• Should run rules (Предпочительные) (а так же anti affinity)

Must run rules – принудительные правила ограничивают HA, DRS и пользователей таким образом, что виртуальная машина может не включиться или же переехать на другой ESX/ESXi хост который не принадлежит ассоциированный DRS host группе.

Should run rules – дает предпочтение DRS-у чтобы запустить виртуальную машину на хосте который указан в ассоциированной DRS host группе.

Два самых характерных примеров использования:

1. Несколько Blade-шасси с серверами и желание обеспечения того, чтобы VM с одинаковым функционалом всегда оставались в пределах разных шасси.

2. Несколько VM с интенсивным обменом данными между собой, которые правильно размещать на одном хосте (например приложение и база данных)

Как это сделать, подробно и в картинках, здесь

Masking a LUN from ESX(i) 4.x

Перепостчу интересную статью:

Начиная с версии ESX(i) 4.0, изменилась процедура маскирования LUN'ов на уровне гипрвизора. Вместо прописывания адресов LUN в Advance Settings -> Disk -> Disk.MaskLUNs, в vSphere для все путей переопределятся плагин PSA на специальный - MASK_PATH.

Для начала удаляем из инвентори все объекты, связанные со скрываемым LUN'ом. Далее:

1. esxcfg-scsidevs -l Первой строчкой описания каждого устройства идёт LUN_ID, запоминаем его для скрываемого LUN'а

2. esxcfg-mpath -L | grep Находим все пути для этого раздела. Запоминаем адрес ввиде: vmhba#:C#:T#:L#, в моём случае vmhba2:C0:T2:L0. При желание, это можно сразу посмотреть в vSphere Client.

3. esxcli corestorage claimrule add --rule 123 -t location -A vmhba2 -C 0 -T 2 -L 0 -P MASK_PATHДобавляем правило в конфигурационных файл. Выбираем любой незанятый номер правила, но обязательно из диапазона 101--200.

4. esxcli corestorage claimrule load Загружаем созданное правило в список активных

5. esxcli corestorage claimrule list Проверяем, что в списке есть два одинаковых правила с выбранным номером с параметрами file и runtime.

6. esxcli corestorage claiming reclaim -d Переопределяем текущие правила для путей раздела на только что созданные.

Всё. Считаем до 10 и LUN больше недоступен для добавления datastor'а. Все пути, помеченные MASK_PATH, переходят в состояние Dead.

По статье kb.

Для чего это нужно? Например, для процедуры корректного удаления LUN'а "на лету":

Удаляем всё с LUN'а-> маскируем его-> отменяем презентацию LUN'а хосту средствами стораджа-> удаляем правила маскирования.

Источник