Changes between Version 7 and Version 8 of ucs/vmware

Timestamp:

2016-06-09T07:19:45Z (8 years ago)

Author:

root

Comment:

--

ucs/vmware

@@ -13 +13 @@
 
 === восхитительный `Cisco UCS`
-скажу откровенно, я довольно нудный тип, которого почти невозможно чем-то восхитить. даже если это получилось, я не всегда захочу это показать, а там где захочу, то не всегда сумею. до того, как я познакомился с блейд-системами `Cisco`, я, честно говоря, даже и не знал что фирма `Cisco` производит сервера. оказалось, производит, да ещё такие, которыми я не устаю восхищаться.
+скажу откровенно, я довольно нудный тип, которого почти невозможно чем-то восхитить. даже если это получилось, я не всегда захочу это показать, а там где захочу, то не всегда сумею. до того, как я познакомился с blade-системами `Cisco`, я, честно говоря, даже и не знал что фирма `Cisco` производит сервера. оказалось, производит, да ещё такие, которыми я не устаю восхищаться.
 
-всю жизнь я работаю с серверами, немного пореже в руки перепадали блейд-системы. когда я первый раз увидел `UCS manager` то стало понятно, что нахрапом его не возьмёшь. почему? хотя бы потому, что кнопочки `вкл` на сервере нет. пока не сформирован `service profile` (профиль) из определённого набора конфигурационных параметров, то железка бесполезна.
+всю жизнь я работаю с серверами, немного пореже в руки перепадали blade-системы. когда я первый раз увидел `UCS manager` то стало понятно, что нахрапом его не возьмёшь. почему? хотя бы потому, что кнопочки `вкл` на сервере нет. пока не сформирован `service profile` (профиль) из определённого набора конфигурационных параметров, то железка бесполезна.
 
-в конфигурационных параметрах профиля из сервера можно вылепить всё что угодно: параметры биос, последовательность загрузки, адреса `ip-kvm`, `hba`, версии прошивок, параметры и `mac`-адреса сетевушек (`iscsi` и обычных). всё это сделано очень гибко, с удобной иерархией и возможностью задавать пулы массово изменяющихся параметров, таких как адреса и маки. соответственно, пока всё это не изучено, то лезвие запустить не получится.
+в конфигурационных параметрах профиля из лезвия можно вылепить всё что угодно: параметры биос, последовательность загрузки, адреса `ip-kvm`, `hba`, версии прошивок, параметры и `mac`-адреса сетевушек (`iscsi` и обычных). всё это сделано очень гибко, с удобной иерархией и возможностью задавать пулы массово изменяющихся параметров, таких как адреса и маки. соответственно, пока всё это не изучено, то лезвие запустить не получится.
 
 === сетевая часть
-о конфигурировании я здесь рассказывать не буду. по этой теме у фирмы `Cisco`, как и для всего остального, есть довольно внятная документация. да и в интернете, в том числе на хабре, об этом написано некоторое количество статей. я хотел бы остановиться на сетевой части блейд-систем `Cisco UCS`. сетевая часть здесь тоже особенная. дело в том, что в серверах-лезвиях отсутствуют сетевые интерфейсы. как же тогда сервера работают с сетью? всё таки сетевой адаптер в каждом лезвии есть: это `Virtual Interface Card` (`vic`).
+о конфигурировании я здесь рассказывать не буду. по этой теме у фирмы `Cisco`, как и для всего остального, есть довольно внятная документация. да и в интернете, в том числе на хабре, об этом написано некоторое количество статей. я хотел бы остановиться на сетевой части blade-систем `Cisco UCS`. сетевая часть здесь тоже особенная. дело в том, что в серверах-лезвиях отсутствуют сетевые интерфейсы. как же тогда лезвия работают с сетью? всё таки сетевой адаптер в каждом лезвии есть: это `Virtual Interface Card` (`vic`).
 
-в комплексе с `IO Module` (`iom`) в корзине эти две железки позволяют создавать реальным серверам виртуальные сетевые интерфейсы в необходимом количестве. оно, конечно, ограничено, но ограничение довольно большое - //[[span(style=color: #FF0000, должно хватить всем)]]//. так зачем же нам сотня сетевых интерфейсов на сервере? незачем, если мы не используем виртуализацию. вот тут-то настаёт время вспомнить о //[[span(style=color: #FF0000, бесполезном)]]// `DirectPath I/O`, который выступает теперь уже совсем в другом свете.
+в комплексе с `IO Module` (`iom`) в корзине эти две железки позволяют создавать реальным серверам виртуальные сетевые интерфейсы в необходимом количестве. оно, конечно, ограничено, но ограничение довольно большое - //[[span(style=color: #FF0000, должно хватить всем)]]//. так зачем же нам сотня сетевых интерфейсов на лезвии? незачем, если мы не используем виртуализацию. вот тут-то настаёт время вспомнить о //[[span(style=color: #FF0000, бесполезном)]]// `DirectPath I/O`, который выступает теперь уже совсем в другом свете.
 
 во второй части [#link1 документации] от `vSphere`, внезапно, обнаруживается, что `DirectPath I/O` на `Cisco UCS` ~~поставляется с блекджеком и шлюхами~~ работает и со снапшотами, и с `fault tolerance`, и с `high availability`, и с `vMotion` за которым неразлучно следует `DRS`. «клёво!» - подумал я, когда прочитал об этом. «сейчас быстро сделаю, будет всем щастье» и обломался. ни в документации `Cisco`, ни в документации `VMWare` я не нашёл чего-то, похожего на инструкцию, как все это сделать. из всего, что мне удалось найти было лишь [#link2 что-то], очень удалённо напоминающее попытку сделать пошаговую инструкцию. этот сайт уже сдох, поэтому ссылка на веб-архив.
@@ -55 +55 @@
 через небольшое время этот `ucs-main` появился в `vcsa`. если этого не произошло, то стоит заглянуть во вкладку `fsm` - скорее всего, там будет написана причина.
 
-=== сервера для гипервизоров
-как я уже упоминал в начале, для того, чтобы в запустить сервер, нужно навесить на него профиль. чтобы это сделать, профиль нужно сначала создать. создание профилей для серверов - это не цель данного документа, поэтому я подразумеваю, что всё необходимое для формирования профиля уже есть. затрагивать я буду только то, что имеет отношение к `vm-fex`, без чего `DirectPath I/O` не заработает. на каждом сервере я буду делать по четыре статических сетевых интерфейса. все четыре будут привязаны к одной фабрике с `failover` на вторую. половина серверов будет работать с фабрикой `а`, другая половина, соответственно, с `b`.
+=== лезвия для гипервизоров
+как я уже упоминал в начале, для того, чтобы в запустить лезвие, нужно навесить на него профиль. чтобы это сделать, профиль нужно сначала создать. создание профилей для серверов - это не цель данного документа, поэтому я подразумеваю, что всё необходимое для формирования профиля уже есть. затрагивать я буду только то, что имеет отношение к `vm-fex`, без чего `DirectPath I/O` не заработает. на каждом лезвии я буду делать по четыре статических сетевых интерфейса. все четыре будут привязаны к одной фабрике с `failover` на вторую. половина лезвий будет работать с фабрикой `а`, другая половина, соответственно, с `b`.
 
 первый интерфейс останется в обычном vSwitch. второй интерфейс будет подключен в обычный `vds`. третий интерфейс будет подключен в `ucs-vds`. вообще-то участие интерфейса в виде `uplink` в `ucs-vds` смахивает на атавизм, т.к. от него ничего не зависит. но если этого не сделать, то проброс виртуальных интерфейсов не работает - я проверял :) четвёртый интерфейс я планировал подключить в дополнительный `vds` в виде софтового `cisco nexus 1000v`, чтобы можно было более гибко конфигурировать порты виртуалок, но руки до него пока не дошли.
@@ -76 +76 @@
 
 === создание `vnic template` с группировкой
-для того, чтобы на серверах были сетевые интерфейсы, нужно создать их шаблоны. шаблоны можно использовать напрямую в каждом профиле, а можно сгруппировать через `lan connectivity policy`. во втором случае для каждого серверного профиля или шаблона профиля достаточно будет лишь указать нужный `lan connectivity policy`, который сделает всё необходимое.
+для того, чтобы на лезвии были сетевые интерфейсы, нужно создать их шаблоны. шаблоны можно использовать напрямую в каждом профиле, а можно сгруппировать через `lan connectivity policy`. во втором случае для каждого серверного профиля или шаблона профиля достаточно будет лишь указать нужный `lan connectivity policy`, который сделает всё необходимое.
 
 создаю два шаблона для статических интерфейсов. один шаблон будет работать с фабрикой `a` с `failover` на `b`, второй наоборот.
@@ -87 +87 @@
 
 === создание `bios policy`
-`bios policy` - это настройки bios: то что можно изменить, зайдя в bios setup. нет смысла открывать консоль и заходить туда на каждом сервере, если всё это можно сделать централизованно сразу для пачки серверов.
+`bios policy` - это настройки bios: то что можно изменить, зайдя в bios setup. нет смысла открывать консоль и заходить туда на каждом лезвии, если всё это можно сделать централизованно сразу для пачки лезвий.
 1. вкладка `servers` → `policies` → `root` → пкм по `bios policies` → `create bios policy`:
  a. `name`: `fex`;
@@ -100 +100 @@
 
 === создание `service profile`
-из него формируется то, что будет вешаться непосредственно на сервер и в соответствии с чем железка будет сконфигурирована. серверный профиль можно сделать напрямую, а потом клонировать. но правильней делать его из шаблона, настройки которого будут наследоваться и меняться на всех зависимых серверных профилях. шаблон серверного профиля включает в себя массу настроек, которые здесь не рассматриваются, подразумевая, что они уже выполнены без моей помощи. здесь я рассмотрю только то, что нужно для работы `DirectPath I/O`.
+из него формируется то, что будет вешаться непосредственно на лезвие и в соответствии с чем железка будет сконфигурирована. серверный профиль можно сделать напрямую, а потом клонировать. но правильней делать его из шаблона, настройки которого будут наследоваться и меняться на всех зависимых серверных профилях. шаблон серверного профиля включает в себя массу настроек, которые здесь не рассматриваются, подразумевая, что они уже выполнены без моей помощи. здесь я рассмотрю только то, что нужно для работы `DirectPath I/O`.
 
 вкладка `servers` → `service profile templates` → пкм по `root` → `create service profile template`. `name`: `esxi4-a`, `type`: `updating template`. вторую настройку нельзя будет сменить на готовом шаблоне, поэтому очень важно на забыть установить её при создании.
@@ -106 +106 @@
 в разделе `networking` выставляю `dynamic vnic connection policy` в значение `create a specific dynamic vnic connection policy`. `number of dynamic vnics`. в соответствии с табличкой в [#link7 мануале] значение по-умолчанию у меня здесь `54`: модель `ucs` у меня 6296, модели `iom` во всех корзинах 2208, значит в соответствии с последней строчкой максимальное число `vif` может быть 58 для mtu 9000 и 58 с mtu 1500, всего 116. данная информация соответствует действительности лишь отчасти.
 
-очевидно, что индус, который писал [#link7 мануал] не до конца разобрался в вопросе. правда в том, что если [#созданиеadapterpolicy полиси адаптеров] содержат завышенные значения количества очередей и `ring size`, то 54 динамических интерфейса сервер переварить не может. от завышенных значений я отказаться не могу - на серверах будет огромная нагрузка по трафику, гораздо больше 10 гигабит на порт (о том как это так - напишу дальше). методом математического тыка значений в полисях адаптеров и количества `vif` я выяснил, что в моём случае здесь успешно выставляется число 33 и остаётся небольшой запас для дополнительных статических интерфейсов. вдруг понадобится.
+очевидно, что индус, который писал [#link7 мануал] не до конца разобрался в вопросе. правда в том, что если [#созданиеadapterpolicy полиси адаптеров] содержат завышенные значения количества очередей и `ring size`, то 54 динамических интерфейса лезвие переварить не может. от завышенных значений я отказаться не могу - на серверах будет огромная нагрузка по трафику, гораздо больше 10 гигабит на порт (о том как это так - напишу дальше). методом математического тыка значений в полисях адаптеров и количества `vif` я выяснил, что в моём случае здесь успешно выставляется число 33 и остаётся небольшой запас для дополнительных статических интерфейсов. вдруг понадобится.
 
 именно по этой причине я выбрал схему с четырьмя статическими интерфейсами. 33 динамических интерфейса это много, их действительно //[[span(style=color: #FF0000, должно хватить всем)]]//. но у меня в кластерах есть большое количество полуспящих виртуалок, которым мощная сеть ни к чему. тратить на них один из 33-х динамических интерфейсов - слишком расточительно. поэтому эти виртуалки будут жить на обычном `vds`, пока не начнут требовать большего. а поскольку большинство из них никогда до этого не дойдут, то жить на обычном `vds` они будут постоянно.
 
-`adapter policy`: `nn-vmw-pt`, `protection`: `protected`. это значит, что динамические интерфейсы, которые `ucsm` создаст для `DirectPath I/O` на каждом сервере будут равномерно разбросаны по обоим фабрикам. не могу вспомнить, почему я решил так сделать. возможно, просто интуиция. возможно также, это неверно и динамические интерфейсы стоит прибивать к той же фабрике, что и статические. время покажет. переделать недолго, несложно и виртуалки для переделки останавливать не придётся.
+`adapter policy`: `nn-vmw-pt`, `protection`: `protected`. это значит, что динамические интерфейсы, которые `ucsm` создаст для `DirectPath I/O` на каждом лезвии будут равномерно разбросаны по обоим фабрикам. не могу вспомнить, почему я решил так сделать. возможно, просто интуиция. возможно также, это неверно и динамические интерфейсы стоит прибивать к той же фабрике, что и статические. время покажет. переделать недолго, несложно и виртуалки для переделки останавливать не придётся.
 
 `how do would you like to configure lan connectivity?`: `use connectivity policy`. вот тут-то я и воспользуюсь группировкой шаблонов сетевух интерфейсов, которая создавалась [#шаблонысгруппировкой здесь]. `lan connectivity policy`: `esxi4-trunk-a`.
@@ -120 +120 @@
 шаблона теперь можно создать непосредственно сам профиль. вкладка `servers` → `service profile templates` → `root` → пкм по `esxi4-trunk-a` → `create service profiles from template`. `naming prefix`: `test`, `name suffix starting number`: `1`, `number of instances`: `1`. это значит что из шаблона будет создан единственный профиль c именем `test1`.
 
-теперь нужно ассоциировать профиль с сервером. вкладка `servers` → `service profiles` → `root` → пкм по `test1` → `change service profile association`. выбираю `select existing server` и в появившейся табличке выбираю сам сервер, который нужно ассоциировать с созданным профилем. после нажатия на кнопку `ok` будет вопрос-предупреждение от `ucsm`, что сервер ребутнётся, делаем? отвечаю утвердительно и жду, пока `ucsm` подготовит сервер к работе.
+теперь нужно ассоциировать профиль с лезвием. вкладка `servers` → `service profiles` → `root` → пкм по `test1` → `change service profile association`. выбираю `select existing server` и в появившейся табличке выбираю само лезвие, который нужно ассоциировать с созданным профилем. после нажатия на кнопку `ok` будет вопрос-предупреждение от `ucsm`, что лезвие ребутнётся, делаем? отвечаю утвердительно и жду, пока `ucsm` подготовит лезвие к работе.
 
-пока `ucsm` готовит сервер стоит обратить внимание на вкладку `network` серверного профиля. выглядеть она должна примерно так:[[br]][[Image(viflist.png)]]
+пока `ucsm` готовит лезвие, стоит обратить внимание на вкладку `network` серверного профиля. выглядеть она должна примерно так:[[br]][[Image(viflist.png)]]
 
 после успешного выполнения весь [#созданиеserviceprofile этот] раздел необходимо повторить для создания второго шаблона и профиля, который будет работать с фабрикой `b` вместо фабрики `a`.
@@ -137 +137 @@
 что касается `esxi`, то в версии `5.1` я наступил на весьма неприятный [#link8 баг], который не давал менять конфигурацию `iscsi` через `host profile`. а без профилей, после того, как их уже распробовал, жить очень грустно. кроме того, в `vds` на 5.5 появились фильтры, что весьма приятно. с их помощью можно реализовать функциональность, для которой раньше приходилось ставить `cisco nexus 1000v`. с `esxi` версии `6.0` тоже не сложилось: в `ucs-bxxx-drivers-vmware.2.2.6c.iso/VM-FEX/Cisco/VIC/ESXi_6.0/README.html` написано: `Not supported`.
 
-приступим к свадьбе. в [#vdsдляvm-fex одном] из прошлых разделов я создал `vds`, который уже должен быть в `vcsa`. дело за малым: добавить один из четырёх интерфейсов сервера в `vds`. и тут меня ждал жестокий облом. один из сетевых интерфейсов гипервизора должен быть связан с с одним из аплинков `vds`. вот как выглядит список аплинков ~~здорового человека~~ `vcsa` версии `5.5`:[[br]][[Image(vcsa55uplinks.png)]]
+приступим к свадьбе. в [#vdsдляvm-fex одном] из прошлых разделов я создал `vds`, который уже должен быть в `vcsa`. дело за малым: добавить один из четырёх интерфейсов лезвия в `vds`. и тут меня ждал жестокий облом. один из сетевых интерфейсов гипервизора должен быть связан с с одним из аплинков `vds`. вот как выглядит список аплинков ~~здорового человека~~ `vcsa` версии `5.5`:[[br]][[Image(vcsa55uplinks.png)]]
 
 а вот список аплинков ~~курильщика~~ `vcsa` версии `6.0`:[[br]][[Image(vcsa60uplinks.png)]]