Skip navigation
2011
Deshifrator Hot Shot

Offtop: Отпуск !!!

Posted by Deshifrator Jul 18, 2011

Наступило время долгожданного и заслуженного отдыха!!!!!

otpusk.png

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

Источник: LLDP support added in vSphere 5

LLDP-2.jpg

Более ранние версии vSphere поддерживали для стандартного и распределенного коммутатора только один CDP (Cisco Discovery Protocol) протокол. И вот, в vSphere 5.0, появилась поддержка LLDP протокола.


LLDP (Link Layer Discovery Protocol) - это очень похожий на Cisco CDP протокол. Основная цель двух протоколов - это помощь сетевому администратору в решении различных проблем. Данные протоколы предоставляют администратору подробную информацию о соседних (непосредственно подключенных) сетевых устройствах. Как правило, это соседние свичи, либо маршрутизаторы.


Например, чтобы увидеть текущую Neighbor Table (таблица о соседях) на каком-нибудь устройстве фирмы Cisco, вам нужно выполнить следующую команду:

show cdp neighbors

А вот для свичей, произведенных фирмой HP, команда будет другой:

show lldp info remote

Neighbor таблица строится на основе информации, которую свичи отправляют на все свои порты, как правило, два раза в минуту.


Протокол CDP, поддерживаемый в vSphere 4.x и принадлежащий компании Cisco, является всего лишь одним из многих протоколов подобного назначения. На рынке присутствует, по крайней мере, пять других поставщиков, у которых есть подобные протоколы. Соответственно, если у вас в сети присутствует разношерстное сетевое оборудование, то у вас могут возникнуть различные проблемы несовместимости протоколов между собой. LLDP призван решить эту проблему. На данный момент, HP в своих устройствах на протяжении уже длительного времени поддерживает протокол LLDP. Большинство устройств фирмы Cisco также поддерживают данный протокол. И, в будущем, количество производителей, которые будут включать поддержку протокола LLDP в свои устройства, будет расти, что значительно облегчит жизнь администраторам.


В vSphere 5 протокол LLDP поддерживается только для распределенных коммутаторов, которые становятся доступными, только если у вас есть лицензия Enterprise Plus. Отмечу также, что LLDP поддерживается только для распределенных коммутаторов пятой (5) версии. Для версий 4 и 4.1 поддержки нет.


Чтобы активировать поддержку протокола LLDP, вам нужно перейти в advanced settings и, в поле Type, выбрать "Link Layer Discovery Protocol":

lldp-enable2.png

Обратите внимание на то, что, по умолчанию, распределенный коммутатор будет только слушать "Listen", но не отправлять информацию о себе другим устройствам. Для того, чтобы dvSwitch начал отправлять информацию о себе другим устройствам, нужно изменить "Listen" на "Both". Это поможет сетевым администраторам быстрее решать возможные проблемы, связанные с сетью.

lldp-listen-2.png

Источник: Major Enhancements in esxcli for vSphere 5


Команда esxcli в VMware vSphere 5 претерпела значительное обновление по сравнению с версией VMware vSphere 4.1, в которой было только 6 основных namespaces и 43 команды.


 

NamespaceDescription
corestorageVMware core storage commands
networkVMware networking commands
nmpVMware Native Multipath Plugin (NMP) This is the VMware default implementation of the Pluggable Storage Architecture
swiscsiVMware iSCSI commands
vaaiVaai Namespace containing vaai code
vmsLimited Operations on Virtual Machines


С последним релизом vSphere 5, esxcli теперь включает в общей сложности 10 namespaces и 251 команду! Некоторые пространства имен (англ. namespaces), из vSphere 4.1, такие как corestorage, теперь располагаются под новым пространством имен storage, который содержит в себе и другие пространства имен, имеющие отношение к storage стеку.


 

NamespaceDescription
esxcliCommands that operate on the esxcli system itself allowing users to get additional information
fcoeVMware FCOE commands
hardwareVMKernel hardware properties and commands for configuring hardware
iscsiVMware iSCSI commands
licenseOperations pertaining to the licensing of vmware and third party modules on the ESX host. These operations currently only include updating third party module licenses
networkOperations that pertain to the maintenance of networking on an ESX host. This includes a wide variety of commands to manipulate virtual networking components (vswitch, portgroup, etc) as well as local host IP, DNS and general hsot networking settings
softwareManage the ESXi software image and packages
storageVMware storage commands
systemVMKernel system properties and commands for configuring properties of the kernel core system
vmA small number of operations that allow a user to Control Virtual Machine operations


Для получения полного списка доступных команд esxcli в VMware vSphere 5 вы можете выполнить следующую команду:

# esxcli esxcli command list

Основной целью esxcli является предоставление централизованного, удобного и легкого доступа к управлению хостами ESXi, как локально, в пределах ESXi Shell, так и удаленно, с помощью vCLI или vMA. С выходом vSphere 5.0 большинство функций команд esxcfg-*/vicfg-* были перенесены в esxcli. В недалеком будущем esxcli приобретет полный набор функций, и команды esxcfg-*/vicfg-* попросту устареют и будут удалены. В том числе, устареют и будут удалены утилиты esxupdate и vihostupdate.


Новая версия esxcli для удаленного управления совместима как с ESXi 5, так и с ESX(i) 4.1 хостами. При подключении к хосту VMware ESXi с использованием esxcli, хост автоматически выдаcт список поддерживаемых namespaces. Новые namespaces, реализованные в ESXi 5, не будут доступны на хосте 4.1, но при этом прежние namespaces (4.1) будут доступны. В последней версии esxcli, vSphere API по прежнему скрыт. Поэтому, для того чтобы получить доступ к esxcli (имеется в виду из скриптов), вам по-прежнему нужно использовать локальный (local) esxcli, либо vCLI, vMA или PowerCLI's esxcli командлеты для удаленного использования.


Синтаксис esxcli очень прост для понимания:

esxcli01.png

Чтобы получить более подробную информацию о пространстве имен, вам просто нужно указать опцию --help после нужного вам пространства имен. На диаграмме ниже наглядно показано, как с помощью опции --help можно получить справочную информацию. В данном случае мы получаем список дополнительных namespaces для пространства имен "network".

esxcli1.png

Для того, чтобы получить более детальную информацию о пространстве имен "firewall" можно также воспользоваться опцией --help.

esxcli2.png

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

esxcli3.png

Как вы уже могли догадаться, команда "get" выдает текущий статус межсетевого экрана (firewall). В основном, многие команды интуитивно понятны. Вы увидите, что большинство esxcli namespaces поддерживают команды get, set и list. Другой приятной вещью в esxcli является совместимый результирующий вывод. Это относится как к локальному, так и к удаленному применению. Теперь скрипты писать будет проще.


Вы так же имеете возможность контролировать тип вывода, который генерирует команда esxcli. В качестве типа вы можете выбрать: XML, CSV или ключ-значение (key-value). Чтобы esxcli начала выдавать результат своей работы в нужном нам формате, необходимо в параметре --formatter указать соответствующий тип. Пара xml и ключ-значение работает для всех пространств имен, а csv не для всех, но для большинства.


Итак, для примера давайте выполним предыдущую команду (esxcli network firewall get), только на этот раз изменим тип результирующего вывода на пару ключ-значение.

# esxcli --formatter=keyvalue network firewall get
 
Firewall.DefaultAction.string=DROP
Firewall.Enabled.boolean=false
Firewall.Loaded.boolean=true

В дополнение к типу формата вы можете отображать только определенные, нужные вам столбы, используя для этого --format-param.


Вот пример того, как выглядит список Standard vSwitches без форматирования:

# esxcli network vswitch standard list

vSwitch0
Name: vSwitch0
Class: etherswitch
Num Ports: 128
Used Ports: 6
Configured Ports: 128
MTU: 1500
CDP Status: listen
Beacon Enabled: false
Beacon Interval: 1
Beacon Threshold: 3
Beacon Required By:
Uplinks: vmnic1, vmnic0
Portgroups: ESXSecretAgentNetwork, VM Network, vmk2, vmk1,
Management Network

vSwitch1
Name: vSwitch1
Class: etherswitch
Num Ports: 128
Used Ports: 3
Configured Ports: 128
MTU: 1500
CDP Status: listen
Beacon Enabled: false
Beacon Interval: 1
Beacon Threshold: 3
Beacon Required By:
Uplinks: vmnic2
Portgroups: VMkernel

Вот этот же пример, но на этот раз отображается только: Имя, Количество Портов, MTU, CDP и Порт-группа. Это достигается за счет использования formatter и format-param параметров:

# esxcli --formatter=csv --format-param=fields="Name,Num Ports,MTU,CDP,
Portgroups" network vswitch standard list

Name,NumPorts,MTU,Portgroups,
vSwitch0,128,1500,"ESXSecretAgentNetwork,VM Network,vmk2,vmk1,
Management Network,",
vSwitch1,128,1500,"VMkernel,",

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

Также вы можете прочитать предыдущий мой пост на эту же тему New Command-Line Interface.

Deshifrator Hot Shot

ESXi Firewall

Posted by Deshifrator Jul 15, 2011

Источник: What's New in VMware vSphere 5.0 Platform


VMware vSphere 5.0 в настоящее время поставляется с принципиально новым фаерволом (firewall), который поможет администраторам защитить management интерфейсы на хосте ESXi. Данный брандмауэр предоставляет аналогичные возможности контроля доступа для платформы VMware ESXi, которые ранее были доступны только для платформы VMware ESX. Тем не менее технология, используемая для построения брандмауэра, отличается от той, что использовалась в VMware ESX. Напомню, что в VMware ESX в качестве межсетевого экрана использовался iptables, запущенный в системной консоли (Console Operating System (COS)).


В VMware ESXi управление доступом осуществляется через специальный модуль (firewall module), который расположен между vmknic (VMkernel network adaptor) и виртуальным свичем (virtual switch). Он (в смысле firewall модуль) проверяет пакеты на соответствие ранее заданным правилам, так называемым правилам фаервола (firewall rules). Основываясь на результатах, модуль определяет дальнейшую судьбу пакета, нужно ли его удалить или пропустить дальше. Ниже перечислены основные особенности нового фаервола:


  • Это сервис-ориентированный и stateless (не подобрал подходящего перевода) фаервол.
  • Позволяет ограничивать доступ к службам, основываясь на IP адресе и маске подсети.
  • Графический интерфейс (GUI) похож на VMware ESX firewall.
  • Межсетевой экран можно настроить с помощью новой команды "esxcli".
  • Данный брандмауэр поддерживает Профили Хостов (Host Profiles).


Для конфигурирования VMware ESXi firewall можно использовать уже знакомый (а, может, кому-то еще и незнакомый) сервис-ориентированный графический интерфейс (VMware ESXi firewall GUI), что поможет администраторам при переходе с платформы VMware ESX на ESXi. Чуть ниже будет немного сказано о VMware ESXi firewall GUI.


VMware ESXi Firewall GUI

Управлять межсетевым экраном VMware ESXi можно точно так же, как и межсетевым экраном VMware ESX. Если мы хотим настроить фаервол с использованием графического интерфейса, то нам следует в vSphere Client'e выделить нужный хост ESXi и перейти на вкладку Configuration -> Security Profile.


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

firewall.jpg


VMware ESXi Firewall CLI

Для настройки фаервола существует отдельное пространство имен. Чуть ниже на скриншоте это схематично изображено.

esxcli-firewall.jpg

Команда "get" (esxcli network firewall get) может быть использована для получения подробной информации о текущих настройках межсетевого экрана. Команда "set" (esxcli network firewall set) позволяет пользователям настраивать правила брандмауэра.


Как видно выше, администраторы, используя команду "esxcli", могут достаточно легко и быстро настроить межсетевой экран в соответствии с корпоративной политикой безопасности.

Deshifrator Hot Shot

New Command-Line Interface

Posted by Deshifrator Jul 14, 2011

Источник: What's New in VMware vSphere 5.0 Platform


В vSphere 5.0 появился новый интерфейс командной строки (CLI). На протяжении долгого времени администраторам приходилось применять различные инструменты с уникальным синтаксисом для локального и удаленного администрирования хостов ESXi. Выход VMware vSphere 5.0 знаменует начало процесса перехода на единый интерфейс командной строки, как для локального, так и для удаленного администрирования. (УРА Товарищи!). Что, впоследствии, приведет к уменьшению общего числа CLI-инструментов.


New "esxcli" Command

Новая команда "esxcli" имеет более удобный и интуитивно понятный для пользователя интерфейс (в общем user-friendly интерфейс), который в режиме реального времени позволяет развернуть (показать) синтаксис команды (наверное, по типу как у Csico). По сравнению с VMware vSphere 4 у новой команды "esxcli" был значительно улучшен синтаксис, и расширена её функциональность, чтобы включить дополнительные возможности, ранее недоступные, такие как: настройка сетевых политик, политик безопасности, управление VIBs, настройка и управление межсетевым экраном (firewall).


Команда "esxcli" доступна на каждом хоcте VMware ESXi через VMware shell. Она также доступна в виде дополнительного vCLI пакета, который может быть установлен на любой Windows или Linux операционной системе. Главное, чтобы данная ОС была в списке поддерживаемых систем. Также "esxcli" доступна и в vSphere Management Assistant (vMA).

esxcli.jpg


Formatted "esxcli" Command Output

В новой команде "esxcli" появилась возможность задавать собственный формат вывода. Используя опцию "--formatter", администратор может указать необходимый формат вывода, например XML, пару ключ-значение или список, разделенный запятыми. Возможность задавать свой собственный формат очень упрощает процесс создания сценариев и облегчает процесс генерации различных отчетов. Вот пример того, как это выглядит на практике:

formatter.jpg


"esxcli" Command Authentication

При каждом выполнении команды "esxcli" вы должны обязательно пройти проверку подлинности (аутентификацию). Для аутентификации вы можете выбрать как индивидуальный хост VMware ESXi, так и сервер vCenter. В VMware vSphere 5.0 предоставляются следующие возможности по управлению аутентификацией пользователей:


  • Если вы вошли в систему, используя VMware ESXi shell, то "esxcli" будет использовать учетные данные текущего пользователя.
  • Если вы работаете удаленно, то вы можете указать учетные данные, как часть команды.
  • Вы можете сохранить учетные данные в файл (session file) и, затем, указать имя этого файла в качестве параметра командной строки.
  • Если вы выполняете команду удаленно с Windows сервера, то вы можете сконфигурировать Windows "-PassThroughAuth"
  • Если вы используете vMA, то вы можете воспользоваться "fast pass" аутентификацией.


При удаленной работе, если учетные данные не были указаны, последует приглашение на ввод логина и пароля.


Augmenting "esxcli" with Other Commands

В VMware vSphere 5.0 новая команда "esxcli" заменяет устаревшие "esxcfg-*" подобные команды. Тем не менее, команда "esxcli" пока еще не предоставляет исчерпывающий набор функций. В будущих выпусках возможности "esxcli" будут расширяться, и, в конечном итоге, это приведет к тому, что "esxcli" заменит все НЕ-"esxcli" команды. Но до этого времени вы по-прежнему будете использовать "esxcli" команду совместно с "vicfg-" и другими командами, такими как "vmware-cmd" и "vmkfstools", для устранения неполадок и администрирования хостов VMware ESXi. Конечно, вы так же можете пользоваться возможностями vSphere PowerCLI.


The "localcli" Command

В дополнение к новой  команде "esxcli" в vSphere 5.0 была добавлена команда "localcli". Команда "localcli" - это, в основном, эквивалент команды "esxcli" с заметным исключением. Дело все в том, что команда "localcli" выполняется на сервере в обход локального процесса "hostd", что может помочь "оживить" сервер или, по крайней мере, минимизировать возможный ущерб, в случае, когда процесс "hostd" не отвечает (завис). Рекомендуется использовать данную команду только по прямому указанию из техподдержки VMware. Иначе применение "localcli" может привести к нестабильной работе хоста VMware ESXi.

Пока не вышла vSphere 5, вспомним о том, как нужно (желательно) настроить BIOS сервера перед установкой гипервизора VMware ESX/ESXi 4.1. Вот, что нам рекомендует официальный документ Performance Best Practices for VMware vSphere 4.1:


  • Перепрошить BIOS до последней версии. В общем-то, эта рекомендация относится не только к биосу, но и ко всем другим частям сервера. В частности, не мешало бы перепрошить и биос RAID контроллера сервера до последней версии.

  • Убедитесь, что в биосе нет ограничений на количество ядер на сокет. А то может случиться так, что процессор поддерживает 6 ядер, а используется только 4 из-за ограничения, выставленного в биосе.

  • Включите "Turbo Mode", если ваши процессоры поддерживают данный режим. Более подробную информацию о данном режиме вы можете получить, прочитав вот эту статью.

  • Убедитесь, что Hyper-Threading включен для тех процессоров, которые поддерживают данную технологию. Hyper-threading на Википедии.

  • На NUMA системах отключите node interleaving. В большинстве случаев это даст большую производительность. Более подробно о NUMA архитектуре здесь.

  • Убедитесь в том, что все поддержки аппаратной виртуализации включены (VT-x, AMD-V, EPT, RVI, и так далее).

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

  • Отключите все ненужные устройства (последовательный порт, USB устройства и т.п).

После прочтения вот этой статьи в базе знаний решил написать данную заметку о том, как можно спасти/забэкапить данные на запущенной ВМ с Unix-Like ОС, когда другие методы для спасения данных недоступны или неприменимы. В общем, вот выдержка из приведенной выше статьи:

This article provides information on the alternative Linux command to clone vmdks without powering off a virtual machine. You may want to use this command when:


  • Metadata is corrupted or lost
  • Part of the LUN has been over-written, for example, by an installation of ESX to incorrect LUN

This method may present some advantages over alternatives where the virtual machine is powered on:

  • It is faster than Converter as data is transferred directly to SAN instead of over network
  • It is possible to restart the guest operating system if the procedure fails

vmkfstools -i is not an option where:

  • The virtual machine is powered on and the vmdk is locked
  • You cannot create snapshot because you cannot risk an update to metadata

VMware Converter may not be an option where:

  • The guest operating system is non-Windows. For example, Linux (pre-VMware Converter 4.0), Netware or Solaris
  • Insufficient diskspace on LUN for snapshots continue to grow while the guest operating system is running

То есть, достаточно много случаев, когда нас может выручить или даже спасти утилита dd. Более подробную информацию о программе dd вы можете получить, прочитав соответствующую статью на википедии. И так, чтобы склонировать жесткий диск на запущенной ВМ с Unix-Like системой, вам нужно в эту виртуальную машину дополнительно добавить новый жесткий диск (vHDD) и, затем, выполнить следующую команду:

# dd if=/dev/sda of=/dev/sdb bs=16M conv=sync,noerror

/dev/sda - это диск с важными данными, /dev/sdb - пустой диск, на который будут скопированы все данные с диска /dev/sda. Синтаксис команды для разных систем может слегка отличаться, поэтому перед выполнением команды загляните в man. После завершения клонирования вы можете второй жесткий диск отцепить от виртуальной машины и прицепить его к другой ВМ, чтобы убедиться, что все данные на месте. Лично я использую dd уже достаточно давно. У меня есть почтовый сервер на базе FreeBSD, на котором периодически по крону запускается скрипт, который, в свою очередь, запускает команду dd для копирования всех данных на удаленный FTP сервер. Вот содержание моего скрипта (может, кому пригодится):

#!/usr/local/bin/bash
######################################
#       -= sfull_backup.sh =-        #
######################################

   VERSION="0.3";
   OK_CODE=0;
   ERROR_CODE=1;
   DUMP_PARTITION='root var usr data';
   FS="";

   bkp_date="`date +%Y-%m-%d`";
   bkp_time="`date +%H:%M:%S`";
   EMAIL="postmaster@example.org";
   ARCH_DIR="/data/msrv/arch";
   LOG_FILE="/var/log/sfull_backup.log";

   FTP_SERVER="10.5.5.21"
   FTP_USER="user"
   FTP_PASS="password"

   #-----------------------------------------------------------------------------------------
   function write_log () { local _WLOG_LOG_FILE="$LOG_FILE"; printf "$1" >> "$_WLOG_LOG_FILE" 2>/dev/null; return $OK_CODE; }
   function email_report_send () { local _ERS_EMAIL="$EMAIL"; local _ERS_LOG_FILE="$LOG_FILE"; write_log "=================================================================================================================\n\n"; cat $_ERS_LOG_FILE 2>/dev/null | mail -sSYSTEM_FULL_BACKUP ${_ERS_EMAIL} 2>/dev/null; return $OK_CODE; }
   #-----------------------------------------------------------------------------------------
   if ! [[ -f "$LOG_FILE" ]]
   then
      touch "$LOG_FILE" >/dev/null 2>&1; if [[ $? -ne 0 ]]; then exit $ERROR_CODE; fi
      chown root:wheel "$LOG_FILE" >/dev/null 2>&1;
      chmod 744 "$LOG_FILE" >/dev/null 2>&1;
   else
      cat /dev/null > "$LOG_FILE" 2>/dev/null;
   fi
   write_log "\n========================================\n";
   write_log "System Full Backup [$bkp_date $bkp_time]\n";
   write_log "=================================================================================================================\n";
   write_log "#################################################################################################################\n";

   chflags -R nodump $ARCH_DIR >/dev/null 2>&1;
   if [[ $? -ne 0 ]]; then write_log "ERROR: chflags\n"; email_report_send; exit $ERROR_CODE; else write_log "INFO: chflags successfully.\t[ `ls -ldo $ARCH_DIR` ]\n"; fi

   #-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   for i in $DUMP_PARTITION; do
      if [[ "$i" == "root" ]]; then FS="/"; else FS="/$i"; fi
      if [[ "$1" == "debug" ]]
         then /sbin/dump -h 0 -0auL -P "/usr/bin/ftp -u ftp://$FTP_USER:$FTP_PASS@$FTP_SERVER/$i.dump -" "$FS";                 if [[ $? -ne 0 ]]; then write_log "ERROR: $i.dump\n"; else write_log "INFO: $i.dump successfully.\n"; fi
         else /sbin/dump -h 0 -0auL -P "/usr/bin/ftp -u ftp://$FTP_USER:$FTP_PASS@$FTP_SERVER/$i.dump -" "$FS" >/dev/null 2>&1; if [[ $? -ne 0 ]]; then write_log "ERROR: $i.dump\n"; else write_log "INFO: $i.dump successfully.\n"; fi
      fi
   done
   write_log "#################################################################################################################\n";
   #-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

   write_log "\n/etc/dumpdates:\n";
   cat /etc/dumpdates >> "$LOG_FILE" 2>/dev/null;
   email_report_send;

exit $OK_CODE;
######################################

Если выполнить данный скрипт с единственным параметром debug:

# ./sfull_backup.sh debug

то на stdout можно будет подробно наблюдать весь процесс создания резервной копии системы, отдельного диска или раздела. Если запустить скрипт без параметров, то он молча отработает, отправив по окончанию отчет о своей работе на электронный адрес. У меня данный скрипт без параметров запускается по крону каждую ночь. Работает стабильно. По крайней мере, у меня. Чуть ниже, на всякий случай, прикладываю файл данного скрипта.

Jason Boche в своём блоге опубликовал интересное интервью, взятое у сотрудника VMware Susan Gudenkauf, основной задачей которого является помощь клиентам в осуществлении перехода на гипервизор нового поколения ESXi. Как я уже выше писал, интервью получилось познавательным и интересным, поэтому его стоит прочитать:


Kenneth van Ditmarsch в своём блоге www.virtualkenneth.com опубликовал статью



в которой хорошо рассказал о различных плюсах и минусах размещения файла подкачки (.vswp) ВМ на отдельном, нереплицируемом, хранилище при использовании SRM. Полезное чтиво.