tag:blogger.com,1999:blog-53201670985697976522024-02-20T05:06:12.725+03:00Записки виртуального админаНовости, обзоры и заметки о виртуальных машинах и платформах виртуализации.Anton Zhbankovhttp://www.blogger.com/profile/00989828695484228304noreply@blogger.comBlogger422125tag:blogger.com,1999:blog-5320167098569797652.post-41520624460493423692018-02-02T18:50:00.004+03:002018-02-02T18:50:46.276+03:00Тестирование производительности гиперконвергентных систем и SDS своими руками- Штурман, приборы!<br />
- 36!<br />
- Что 36?<br />
- А что приборы?<br />
<br />
Примерно так на сегодня выглядит большинство синтетических тестов систем хранения данных. Почему так?<br />
<br />
До относительно недавнего времени большинство СХД были плоскими с равномерным доступом. Что это означает?<br />
Общее доступное дисковое пространство было собрано из дисков с одинаковыми характеристиками. Например 300 дисков 15k. И производительность была одинаковой по всему пространству. С появлением технологии многоуровневого хранения, СХД стали неплоскими - производительность различается внутри одного дискового пространства. Причем не просто различается, а еще и непредсказуемо, в зависимости от алгоритмов и возможностей конкретной модели СХД.<br />
И все было бы не так интересно, не появись гиперконвергентные системы с локализацией данных. Помимо неравномерности самого дискового пространства появляется еще и неравномерность доступа к нему - в зависимости от того, на локальных дисках узла лежит одна из копий данных или за ней необходимо обращаться по сети.<br />
Привычные синтетические тесты резко дают маху, цифры от этих нагрузок потеряли практический смысл. Единственный способ всерьез оценить подходит ли система - это пилотная инсталляция с перенесением продуктива. Но что делать, если на перенос продуктива не дает добро безопасность или это просто слишком долго / трудоемко. Есть ли способ оценки?<br />
<br />
<cut/><br />
Сделаем вид, что мы продуктивная нагрузка, и нагрузим весь гиперконвергентный кластер. Смело вычеркиваем "100% random по всему объему" - этот тест не покажет ровным счетом ничего, кроме производительности самых нижних дисков. Т.е. 150-300 IOPS на узел (2-4 SATA). <br />
<br />
Что для этого требуется? <br />
<br />
1. Минимум по 1 машине с генератором нагрузки на узел.<br />
2. Профили нагрузки, приближенные к продуктиву.<br />
<br />
Для массовых нагрузок типа VDI необходимо создание репрезентативного количества машин. В идеале конечно полного, но поскольку большинство демо-систем - это 3-4 узла, то 3000-4000 ВМ на них конечно никак не запустить.<br />
<br />
В моих цепких лапах оказался кластер Nutanix NX-3460G4, но тест применим к любой платформе, доступной на рынке. Более того, те же самые тесты можно проводить и для классических СХД, технология никак не меняется.<br />
<br />
<img src="https://habrastorage.org/webt/b9/aw/on/b9awonhvzyal11y4pwmguzbkjpw.png" alt="image"/><br />
<br />
В качестве генератора нагрузки я взял FIO под управлением CentOS 7. Профили нагрузок от <a href="https://www.nutanix.com/xray/">Nutanix XRay 2.2</a>. Почему CentOS? Был дистрибутив под рукой, можно использовать любой другой Linux по вкусу.<br />
Делаем несколько шаблонов ВМ под разный тип нагрузки.<br />
<br />
1. Управляющая FIO - 1 vCPU, 2GB RAM, 20GB OS<br />
2. DB - 1 vCPU, 2GB RAM, 20GB OS, 2*2 GB Log, 4*28 GB Data<br />
3. VDI - 1 vCPU, 2GB RAM, 20GB OS, 10 GB Data<br />
<br />
Создаем управляющую FIO. Ставим CentOS в минимальной установке на 20GB диск, остальные не трогаем.<br />
<br />
После минимальной установки CentOS ставим FIO<br />
<b>#</b> yum install wget<br />
<b>#</b> wget http://dl.fedoraproject.org/pub/epel/testing/7/x86_64/Packages/f/fio-3.1-1.el7.x86_64.rpm<br />
<b>#</b> yum install fio-3.1-1.el7.x86_64.rpm<br />
<br />
Повторяем то же самое для машин шаблонов нагрузки. И прописываем FIO в автозагрузку на них.<br />
Создаем файл <b>/etc/systemd/system/fio.service</b><br />
<br />
<code>[Unit]<br />
Description=FIO server<br />
After=network.target<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=/usr/bin/fio --server<br />
Restart=on-failure<br />
RestartSec=5<br />
<br />
[Install]<br />
WantedBy=multi-user.target</code><br />
<br />
<b>#</b> systemctl daemon-reload<br />
<b>#</b> systemctl enable fio.service <br />
<b>#</b> systemctl start fio.service<br />
<b>#</b> firewall-cmd --zone=public --permanent --add-port=8765/tcp<br />
<br />
Инфраструктура готова. Теперь нужна нагрузка.<br />
Создадим список серверов FIO.<br />
10.52.8.2 - 10.52.9.146<br />
<br />
Удобно использовать для этого Excel.<br />
<br />
<img src="https://habrastorage.org/webt/cn/vp/ix/cnvpixisb8k-fvy3kkthoaq6wxe.png" alt="image"/><br />
<br />
Загружаем этот список на управляющую машину. На нее же загружаем конфиг-файлы FIO c нагрузкой.<br />
<br />
<b>fio-vdi.cfg</b><br />
<br />
<code>[global]<br />
ioengine=libaio<br />
direct=1<br />
norandommap<br />
time_based<br />
group_reporting<br />
disk_util=0<br />
continue_on_error=all<br />
rate_process=poisson<br />
runtime=3600<br />
<br />
[vdi-read]<br />
filename=/dev/sdb<br />
bssplit=8k/90:32k/10,8k/90:32k/10<br />
size=8G<br />
rw=randread<br />
rate_iops=13<br />
iodepth=8<br />
percentage_random=80<br />
<br />
[vdi-write]<br />
filename=/dev/sdb<br />
bs=32k<br />
size=2G<br />
offset=8G<br />
rw=randwrite<br />
rate_iops=10<br />
percentage_random=20</code><br />
<br />
<b>fio-oltp.cfg</b><br />
<br />
<code>[global]<br />
ioengine=libaio<br />
direct=1<br />
time_based<br />
norandommap<br />
group_reporting<br />
disk_util=0<br />
continue_on_error=all<br />
rate_process=poisson<br />
runtime=10000<br />
<br />
[db-oltp1]<br />
bssplit=8k/90:32k/10,8k/90:32k/10<br />
size=28G<br />
filename=/dev/sdd<br />
rw=randrw<br />
iodepth=8<br />
rate_iops=500,500<br />
<br />
[db-oltp2]<br />
bssplit=8k/90:32k/10,8k/90:32k/10<br />
size=28G<br />
filename=/dev/sde<br />
rw=randrw<br />
iodepth=8<br />
rate_iops=500,500<br />
<br />
[db-oltp3]<br />
bssplit=8k/90:32k/10,8k/90:32k/10<br />
size=28G<br />
filename=/dev/sdf<br />
rw=randrw<br />
iodepth=8<br />
rate_iops=500,500<br />
<br />
[db-oltp4]<br />
bssplit=8k/90:32k/10,8k/90:32k/10<br />
size=28G<br />
filename=/dev/sdg<br />
rw=randrw<br />
iodepth=8<br />
rate_iops=500,500<br />
<br />
[db-log1]<br />
bs=32k<br />
size=2G<br />
filename=/dev/sdb<br />
rw=randwrite<br />
percentage_random=10<br />
iodepth=1<br />
iodepth_batch=1<br />
rate_iops=100<br />
<br />
[db-log2]<br />
bs=32k<br />
size=2G<br />
filename=/dev/sdc<br />
rw=randwrite<br />
percentage_random=10<br />
iodepth=1<br />
iodepth_batch=1<br />
rate_iops=100</code><br />
<br />
Запустим FIO в для проверки правильности настроек и первичного прогрева дисков.<br />
<br />
На управляющей ВМ<br />
<br />
<b>#</b> fio --client <fio.template.ip> vdi.cfg<br />
<br />
Минуты через 2-3 можно нажать Ctrl-C, иначе FIO отработает полный цикл из конфига - 2 часа.<br />
<br />
Теперь подготовим площадку под массовое развертывание VDI нагрузки. Я создал совершенно непересекающуюся сеть с IPAM - гипервизор AHV перехватывает DHCP и выдает адреса сам. <br />
<br />
<img src="https://habrastorage.org/webt/ho/7u/c-/ho7uc-g0o9g2i1w2jitqhadufce.png" alt="image"/><br />
<br />
Поскольку AHV выдает адреса не по порядку, сделаем пул размером ровно под планируемую нагрузку - 400 ВМ (по 100 на хост).<br />
<br />
<img src="https://habrastorage.org/webt/hb/uz/kv/hbuzkvtqwq_a0hmwzqdnsley3tw.png" alt="image"/><br />
<br />
Создаем нагрузочные 400 машин VDI. <br />
<br />
<img src="https://habrastorage.org/webt/gi/u_/6z/giu_6zcfqedhto6xapgobrswuc8.png" alt="image"/><br />
<br />
<img src="https://habrastorage.org/webt/6a/r-/dl/6ar-dlr0ilbosapq8uxwa31yros.png" alt="image"/><br />
<br />
В принципе только создание сразу 400 машин уже интересный тест любой системы.<br />
Как у нас справился немолодой уже кластер Nutanix?<br />
<br />
<img src="https://habrastorage.org/webt/-b/8h/75/-b8h75hjqcjr7khexyk5dv4pavm.png" alt="image"/><br />
<br />
2 минуты. Мне кажется, отличный результат.<br />
<br />
Теперь включаем машины. <br />
<br />
На Nutanix CVM<br />
<b>#</b> acli vm.on fio-vdi-*<br />
<br />
Ну и теперь самое время врубить полный газ! <br />
С управляющей FIO<br />
<b>#</b> fio --client vdi.list vdi.cfg<br />
<br />
Примерно так ваша СХД будет себя чувствовать под 400 ВМ со средней офисной VDI нагрузкой.<br />
<br />
Так же в статье указаны профили для средней OLTP и DSS БД. Их, конечно не по 400, но штук 6-8 можно запустить и попробовать. Например для 8 OLTP и 2 DSS нам потребуется 10 машин из тех, что имеют по 6 дополнительных дисков.<br />
<br />
С двух терминалов сразу<br />
1. <b>#</b> fio --client oltp.list fio-oltp.cfg<br />
2. <b>#</b> fio --client dss.list fio-dss.cfg<br />
<br />
Казалось бы, все идет хорошо. Каждая система показывает себя неплохо, и ничего не предвещает беды. Сделаем беду сами!<br />
<br />
<img src="https://habrastorage.org/webt/36/u4/xt/36u4xte0ti6vxhheyb4ufwxqxdu.png" alt="image"/><br />
<br />
Теперь наблюдаем как под нагрузкой система будет перестраиваться и как это изменит показатели. Особое внимание обратите на "умные" системы, которые откладывают перестроение и восстановление отказоустойчивости на час и более. Не, ну а что такого? А вдруг это ничего страшного нет, подумаешь узел вылетел. Зато на тестах красивые цифры останутся. Если не читать то, что мелким шрифтом в глубинах документации.<br />
Nutanix начинает процесс восстановления автоматически, через 30 секунд после недоступности CVM. Даже если это легитимная операция как например перезагрузка при обновлении.<br />
<br />
При помощи подобного нехитрого руководства можно попробовать - а подходит ли вам предлагаемая вендором / интегратором система.<br />
Ну или конечно, вы можете просто скачать Nutanix XRay, которая сделает все это в автоматическом режиме с красивыми графиками для платформ Nutanix AHV и VMware! :)<div class="blogger-post-footer"><br/>--
<br/><a href="http://blog.vadmin.ru">http://blog.vadmin.ru</a> - Записки виртуального админа</div>Anton Zhbankovhttp://www.blogger.com/profile/00989828695484228304noreply@blogger.com0tag:blogger.com,1999:blog-5320167098569797652.post-55801506048315796262018-01-05T13:45:00.000+03:002018-03-20T23:57:50.370+03:00Meltdown and Spectre<div dir="ltr" style="text-align: left;" trbidi="on">
В России все еще продолжаются праздники, но весь мир уже третий день будоражит известие о новых уязвимостях, которым подвержены большинство современных CPU.<br />
<br />
Как всегда, подобные известия создают множество слухов, провокаций и откровенно глупостей.<br />
<br />
Пока, реально оценить угрозу и все произошедшее мало кто может. Давайте не поддаваться панике, <b>внимательно</b> читать <b>первоисточники</b> и принимать <b>разумные</b> решения.<br />
<br />
<br />
"Официальный" сайт с описанием найденных уязвимостей: <a href="https://meltdownattack.com/">https://meltdownattack.com</a><br />
<br />
Проект Project Zero с подробным техническим описанием уязвимостей: <a href="https://googleprojectzero.blogspot.ru/2018/01/reading-privileged-memory-with-side.html">https://googleprojectzero.blogspot.ru/2018/01/reading-privileged-memory-with-side.html</a><br />
<div>
<br /></div>
<div>
Еще технические детали от Google: <a href="https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html">https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html</a><br />
<div>
<br />
Многие вендоры уже выпустили свои информационные бюллетени, ищем их на сайте уязвимости, внизу страницы есть ссылки: <a href="https://meltdownattack.com/">https://meltdownattack.com</a><br />
<br />
Список ссылок на информационные бюллетени вендоров также есть на reddit:<br />
<a href="https://www.reddit.com/r/networking/comments/7o4y40/meltdownspectre_vulnerability_tracker/">https://www.reddit.com/r/networking/comments/7o4y40/meltdownspectre_vulnerability_tracker/</a><br />
<br />
<b>Что касается VMware</b><br />
<b><br />
</b> Используем только проверенные источники/первоисточники, на сайте VMware раздел с описание уязвимостей: <a href="https://www.vmware.com/security/advisories.html">https://www.vmware.com/security/advisories.html</a><br />
<br />
Согласно VMSA-2018-0002 патчи для ESXi были выпущены еще 19 декабря 2017, их нужно устанавливать: <a href="https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html">https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html</a><br />
<br />
Гостевые ОС <b>также</b> подвержены уязвимостям, следим за новостями у производителей ОС, ссылки есть здесь: <a href="https://meltdownattack.com/">https://meltdownattack.com</a><br />
<br />
Следим за блогом VMware Security & Compliance Blog. Например, сегодня появилась информация о vRealize Operations for Horizon, vRealize Operations for Published Applications, Workstation, Horizon View Client and Tools: <a href="https://blogs.vmware.com/security">https://blogs.vmware.com/security</a><br />
<br />
VMware выпустили статью с описанием уязвимостей в Virtual Appliances: <a href="https://kb.vmware.com/s/article/52264">https://kb.vmware.com/s/article/52264</a><br />
<br />
<b>И еще раз, будем внимательны, следим за официальными источниками информации, не "ведемся" на слухи и провокации, осознав прочитанное принимаемся за работу.</b><br />
<br />
Всем успехов!<br />
<br />
<br />
<b>UPD. История продолжается, прилетели новые обновления для ESXi и vCenter: </b><a href="https://www.vmware.com/us/security/advisories/VMSA-2018-0004.html">https://www.vmware.com/us/security/advisories/VMSA-2018-0004.html</a><br />
<br />
<b>UPD. Патчи из VMSA-2018-0004 пока лучше не ставить:</b><br />
<a href="https://kb.vmware.com/s/article/52345">https://kb.vmware.com/s/article/52345</a><br />
<br />
<b>UPD. Вышел новый эпизод:</b><br />
<a href="https://www.vmware.com/us/security/advisories/VMSA-2018-0004.html">https://www.vmware.com/us/security/advisories/VMSA-2018-0004.html</a><br />
<br /></div>
</div>
</div>
<div class="blogger-post-footer"><br/>--
<br/><a href="http://blog.vadmin.ru">http://blog.vadmin.ru</a> - Записки виртуального админа</div>Grigory Pryalukhinhttp://www.blogger.com/profile/06924576956173428091noreply@blogger.com1tag:blogger.com,1999:blog-5320167098569797652.post-64616355242279078452017-12-14T13:15:00.000+03:002017-12-21T00:58:00.303+03:00Nutanix User Group Russia 2017 Друзья, рад объявить о проведении Nutanix User Group Russia (sponsored by Intel).<br />
<br />
Уже зарегистрировалось более 100 человек.<br />
<br />
Будет проходить в Москве 20-го декабря. С 14-00 и до упора.<br />
Место проведения - HopHead, Москва.<br />
<br />
Будет много интересного - покажем Nutanix 5.5 (включая микросегментацию), будут доклады партнеров, заливное море крафтового пива, вкусная еда и прочие приятности.<br />
<br />
Выступления партнеров: <br />
Intel - Новинки Intel для гиперконвергентных сред (Xeon Scalable, Optane, 3D Nand, Ethernet)<br />
Citrix - "Как размножаются ёжики - MCS vs PVS для VDI"<br />
BitDefender - Защита данных в виртуальных средах<br />
Arista - Сеть в эпоху гиперконвергентности<br />
<br />
<div class="blogger-post-footer"><br/>--
<br/><a href="http://blog.vadmin.ru">http://blog.vadmin.ru</a> - Записки виртуального админа</div>Anton Zhbankovhttp://www.blogger.com/profile/00989828695484228304noreply@blogger.com0tag:blogger.com,1999:blog-5320167098569797652.post-49842845130025854532017-09-25T12:29:00.000+03:002017-10-06T17:03:33.546+03:00Восстанавливаем файловую систему загрузочного диска ESXi<div dir="ltr" style="text-align: left;" trbidi="on">
Столкнулся с проблемой установки/обновления VMware Tools на машинах, работающих на одном из хостов в кластере:<br />
<br />
<a href="https://4.bp.blogspot.com/-wkcYSX-YxSM/WcI1cgQF-VI/AAAAAAAAFC4/hpXPGmWOdCg09pMZD46NJymaJgq_g_MsACLcBGAs/s1600/Screen%2BShot%2B2017-09-18%2Bat%2B15.00.47.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="527" data-original-width="805" height="261" src="https://4.bp.blogspot.com/-wkcYSX-YxSM/WcI1cgQF-VI/AAAAAAAAFC4/hpXPGmWOdCg09pMZD46NJymaJgq_g_MsACLcBGAs/s400/Screen%2BShot%2B2017-09-18%2Bat%2B15.00.47.png" width="400" /></a><br />
<br />
С машинами, работающими на других хостах кластера такой проблемы нет, можно без ошибок установить/обновить VMware Tools.<br />
После прочтения, предложенного в сообщении об ошибке KB <a href="https://kb.vmware.com/kb/2129825" target="_blank">Installing and upgrading the latest version of VMware Tools on existing hosts</a>, подключился по SSH к проблемному хосту и обнаружил следующую картину:<br />
<br />
<a href="https://3.bp.blogspot.com/-9gc_cpXE_t4/WcI1VciNXVI/AAAAAAAAFC0/yXWg9jOZcwAnRMbDcWose1R-5E4eTfE0gCLcBGAs/s1600/Screen%2BShot%2B2017-09-18%2Bat%2B16.12.28.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="836" data-original-width="1322" height="404" src="https://3.bp.blogspot.com/-9gc_cpXE_t4/WcI1VciNXVI/AAAAAAAAFC0/yXWg9jOZcwAnRMbDcWose1R-5E4eTfE0gCLcBGAs/s640/Screen%2BShot%2B2017-09-18%2Bat%2B16.12.28.png" width="640" /></a><br />
<br />
Файловая система раздела, содержащего VMware Tools разрушена.<br />
Первая мысль переустанавливать ESXi с нуля, но подумав пару минут, пришло осознание, ESXi все-таки Linux и должен быть путь «починить» файловую систему раздела без полной переустановки ESXi.<br />
<br />
Возможно, данная проблема связана с KB <a href="https://kb.vmware.com/kb/2149257" target="_blank">High frequency of read operations on VMware Tools image may cause SD card corruption</a>.<br />
Начиная с ESXi 6.0 U3 появился дополнительный параметр, который позволяет при загрузке ESXi создать RAM диск, содержащий образы VMware Tools. Это снизит нагрузку на загрузочный диск при многократной установке VMware Tools.<br />
<br />
Итак, первым делом выводим хост в <b>Maintenance Mode</b>.<br />
Далее, нужно понять какой раздел смонтирован в папку /store (locker – это ссылка на store). Для это этого выполним команду:<br />
<blockquote>
vmkfstools -P /store</blockquote>
Обычно это 8 раздел загрузочного устройства (почему 8 раздел можно прочитать в статье <a href="http://blog.vadmin.ru/2017/06/esxi-c-usbsd-vsan.html" target="_blank">Загрузка ESXi c USB/SD и что меняется, когда появляется vSAN</a>):<br />
<br />
<a href="https://2.bp.blogspot.com/-9aQp9G0XHcs/WcI2CwMptZI/AAAAAAAAFDA/36kn2NwqivsCd2pNwMsVgE1_qy17rnJdgCLcBGAs/s1600/Screen%2BShot%2B2017-09-20%2Bat%2B11.24.06.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="836" data-original-width="1322" height="404" src="https://2.bp.blogspot.com/-9aQp9G0XHcs/WcI2CwMptZI/AAAAAAAAFDA/36kn2NwqivsCd2pNwMsVgE1_qy17rnJdgCLcBGAs/s640/Screen%2BShot%2B2017-09-20%2Bat%2B11.24.06.png" width="640" /></a><br />
<br />
Запускаем проверку диска для 8 раздела загрузочного диска:<br />
<blockquote>
dosfsck -a -w /dev/disks/mpx.vmhba32:C0:T0:L0:8</blockquote>
Бывает, что требуется ручное исправление ошибок на диске, тогда:<br />
<blockquote>
dosfsck -v -w -r /dev/disks/mpx.vmhba32:C0:T0:L0:8</blockquote>
Далее, удаляем содержимое папки /store и перезагружаем проблемный хост:<br />
<blockquote>
rm -r /store/*</blockquote>
При загрузке ESXi восстановит необходимые файлы и папки в store, но vib пакет с VMware Tools нам придется восстановить руками, можно это сделать, например, через Update Manager:<br />
<br />
<br />
<a href="https://1.bp.blogspot.com/-DCL7PSjifxA/WcI2tB1G2oI/AAAAAAAAFDI/su728teZhtwbzZ8nMZFuzZTVxz_dIqEPQCLcBGAs/s1600/Screen%2BShot%2B2017-09-19%2Bat%2B17.27.10.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="941" data-original-width="1600" height="376" src="https://1.bp.blogspot.com/-DCL7PSjifxA/WcI2tB1G2oI/AAAAAAAAFDI/su728teZhtwbzZ8nMZFuzZTVxz_dIqEPQCLcBGAs/s640/Screen%2BShot%2B2017-09-19%2Bat%2B17.27.10.png" width="640" /></a><br />
<br />
К сожалению, я сталкивался с ситуациями, когда USB/SD карты выходили из строя или «ломались» партиции на них. Вообщем, разбираться и «чинить» точно бы заняло кучу времени.<br />
На этот случай есть возможность создания резервной копии конфигурации ESXi и последующего восстановления из нее. Все это описано в <a href="https://kb.vmware.com/kb/2042141" target="_blank">KB How to back up ESXi host configuration</a>. Данная процедура работает и для хостов с VMware vSAN без необходимости эвакуировать данные с проблемного хоста.<br />
<br />
Делаем резервную копию конфигурации, например, через PowerCLI:<br />
<blockquote>
Connect-VIServer -Server host_ip<br />
Get-VMHostFirmware -VMHost host_ip -BackupConfiguration -DestinationPath C:\Temp</blockquote>
Переустанавливаем ESXi с нуля. И восстанавливаем настройки из резервной копии:<br />
<blockquote>
Connect-VIServer -Server host_ip<br />
Set-VMHost -VMHost -State 'Maintenance'<br />
Set-VMHostFirmware -VMHost host_ip -Restore -SourcePath C:\Temp\configBundle host_ip.tgz -HostUser root -HostPassword Password</blockquote>
</div>
<div class="blogger-post-footer"><br/>--
<br/><a href="http://blog.vadmin.ru">http://blog.vadmin.ru</a> - Записки виртуального админа</div>Grigory Pryalukhinhttp://www.blogger.com/profile/06924576956173428091noreply@blogger.com0tag:blogger.com,1999:blog-5320167098569797652.post-65999246992963005982017-09-18T12:49:00.001+03:002017-09-18T16:29:25.453+03:00Перезапуск Management agents в ESXi и терпение<div dir="ltr" style="text-align: left;" trbidi="on">
Бывает такое, что ESXi отключается от vCenter, но виртуальные машины, запущенные на нем, продолжают работать, это означает, что проблема в сервисах гипервизора, отвечающих за коммуникацию с vCenter'ом (<a href="https://kb.vmware.com/kb/1003409" target="_blank">Troubleshooting an ESXi/ESX host in non responding state</a>).<br />
<br />
<a href="https://4.bp.blogspot.com/-Dkj9drc3ug4/Wb-JUWwt0dI/AAAAAAAAFCY/2MygxKoijvUE1cwF0A57nTggk0s4d8ApACLcBGAs/s1600/Screen%2BShot%2B2017-09-17%2Bat%2B23.39.49.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="246" data-original-width="704" height="138" src="https://4.bp.blogspot.com/-Dkj9drc3ug4/Wb-JUWwt0dI/AAAAAAAAFCY/2MygxKoijvUE1cwF0A57nTggk0s4d8ApACLcBGAs/s400/Screen%2BShot%2B2017-09-17%2Bat%2B23.39.49.png" width="400" /></a><br />
<br />
Самое очевидное решение, просто их перезапустить, но как раз в этом то может и крыться проблема.<br />
Перезапустить hostd и vpxa (а именно эти сервисы отвечают за связь ESXi и vCenter), согласно <a href="https://kb.vmware.com/kb/1003490" target="_blank">Restarting the Management agents in ESXi</a>, можно через Host Client (https://<esxihost>/ui/), подключившись к хосту через SSH или DCUI.<br />
Как все легко, но обычно, когда есть проблемы с hostd и vpxa, то и Host Client перестает работать и выглядит вот так:<br />
<br />
<a href="https://2.bp.blogspot.com/--jWVSAvjanQ/Wb-HamOIk1I/AAAAAAAAFCM/1qkRBrPIUdIDw7P8qQiFXZvbia_tdqLJwCLcBGAs/s1600/Screen%2BShot%2B2017-09-18%2Bat%2B00.02.11.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1094" data-original-width="1600" height="436" src="https://2.bp.blogspot.com/--jWVSAvjanQ/Wb-HamOIk1I/AAAAAAAAFCM/1qkRBrPIUdIDw7P8qQiFXZvbia_tdqLJwCLcBGAs/s640/Screen%2BShot%2B2017-09-18%2Bat%2B00.02.11.png" width="640" /></a><br />
<br />
При этом по умолчанию SSH на ESXi хостах выключен. И соответственно остается только DCUI - радуемся, что у нас есть iDRAC, iLO, etc. или бежим к серверу.<br />
<br />
Ну и здесь все не без проблем. Нажав F2 в DCUI и введя пароль нас ожидает новая проблема, ничего дальше не происходит, окошко логина висит, а в меню мы попасть не можем. Тут нам поможет только терпение, в таком состоянии логин может идти несколько минут, а бывает, что и 15-20 минут. Ждем.<br />
Дождавшись входа на нужно найти пункт меню <b>Troubleshooting Options</b> и выбрать <b>Restart Management Agents</b>:<br />
<br />
<a href="https://1.bp.blogspot.com/-vsN3b-wqx5M/Wb-Kkjct7SI/AAAAAAAAFCk/ki__-69jYIcZ12sulhPfUuD23ksR6C00ACLcBGAs/s1600/Screen%2BShot%2B2017-09-18%2Bat%2B01.56.28.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1201" data-original-width="1600" height="300" src="https://1.bp.blogspot.com/-vsN3b-wqx5M/Wb-Kkjct7SI/AAAAAAAAFCk/ki__-69jYIcZ12sulhPfUuD23ksR6C00ACLcBGAs/s400/Screen%2BShot%2B2017-09-18%2Bat%2B01.56.28.png" width="400" /></a><br />
<br />
К сожалению, это не всегда помогает, иногда нужно подключится по SSH, почитать логи и выполнить какие-нибудь команды. Проще простого.<br />
Для это нам нужно включить SSH через DCUI, выбираем пункт меню <b>Troubleshooting Options</b> и <b>Enable SSH</b>. Вот здесь нас снова ожидает большой сюрприз, DCUI перестает реагировать на клавиатуру. Это может продолжаться полчаса, а может и несколько часов. Терпение, ждем и SSH включен. Дело за малым, подключиться по SSH и выполнить команды:<br />
<br />
<blockquote>
/etc/init.d/hostd restart<br />
/etc/init.d/vpxa restart</blockquote>
</div>
<div class="blogger-post-footer"><br/>--
<br/><a href="http://blog.vadmin.ru">http://blog.vadmin.ru</a> - Записки виртуального админа</div>Grigory Pryalukhinhttp://www.blogger.com/profile/06924576956173428091noreply@blogger.com3tag:blogger.com,1999:blog-5320167098569797652.post-73903496429547584102017-06-26T08:35:00.000+03:002017-06-27T11:20:54.928+03:00Загрузка ESXi c USB/SD и что меняется, когда появляется vSAN<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: left;">
Я уверен, что каждый из вас устанавливал ESXi тысячи раз, установка настолько простая, что, я думаю, вы даже не успевали задуматься, а что же на самом деле происходит в этот момент.</div>
<div>
В этой статье я предлагаю разобраться подробнее, что же происходит во время установки ESXi. Начнем с того, что согласно документации <a href="http://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.vsphere.upgrade.doc/GUID-DEB8086A-306B-4239-BF76-E354679202FC.html" target="_blank">ESXi Hardware Requirements ESXi</a> можно установить на устройство размером минимум 1GB, это может быть USB stick, SD card, локальный диск, SAN/iSCSI LUN и набирающий популярность, но еще достаточно дрогой вариант – SATADOM, возможно применение vSphere Auto Deploy.</div>
<div>
Лично мне варианты загрузки SAN/iSCSI LUN и vSphere Auto Deploy не нравятся. При проблемах с сетью хост даже не сможет загрузится, что еще сильнее усложнит поиск проблемы. Я не буду рассматривать эти варианты.</div>
<div>
Как было сказано выше для установки ESXi достаточно накопителя объемом 1GB и если мы выберем такой накопитель и посмотрим на разделы, созданные при установке ESXi, то мы увидим следующую картину. Пять обязательных раздела (Начиная с ESXi 4.x MBR был заменен на GPT).</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-lpUefixqqMs/WVA14eqTfeI/AAAAAAAAFAU/DASIvB9SfZgYQ1XJqeJw5WJQ82HImsDJwCLcBGAs/s1600/Picture1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="165" data-original-width="972" height="107" src="https://4.bp.blogspot.com/-lpUefixqqMs/WVA14eqTfeI/AAAAAAAAFAU/DASIvB9SfZgYQ1XJqeJw5WJQ82HImsDJwCLcBGAs/s640/Picture1.png" width="640" /></a></div>
<div>
<ul style="text-align: left;">
<li>Раздел #1. Самый маленький раздел, в нем находится загрузчик.</li>
<li>Раздел #5. Содержит образ операционной системы гипервизора.</li>
<li>Раздел #6. Содержит альтернативный образ операционной системы гипервизора.</li>
<li>Раздел #7. Предназначен для сохранения coredump в случае PSOD (Pink Screen of Death).</li>
<li>Раздел #8. Содержит образы VMware Tools и Floppy Images.</li>
</ul>
</div>
<div>
Все, вроде, очевидно кроме раздела #5 и раздела #6.</div>
<div>
Основное отличие от традиционной операционной системы в ESXi - это то, что все файлы, необходимые гипервизору, хранятся в разделе фиксированного объема (Primary Boot Bank - 250 МБ). Альтернативный Boot Bank такого же размера необходим на случай отката к предыдущей версии ESXi вне зависимости от того был ли произведен Update (накатывание патчей) или Upgrade (накатывание новой версии ESXi). При обновлении ESXi не перезаписывает предыдущую версию, а создает новый образ операционной системы гипервизора и сохраняет возможность «откатиться» в случае неудачного обновления.</div>
<div>
Нажав «SHIFT+R» при загрузке гипервизора мы можем выбрать версию для загрузки.</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-UO_y-oaTSb0/WVA2DQ1AM3I/AAAAAAAAFAY/o_hQS7YPpVYDgrJgPv8jGCKSEVEuXhNEACLcBGAs/s1600/Picture2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="436" data-original-width="973" height="286" src="https://4.bp.blogspot.com/-UO_y-oaTSb0/WVA2DQ1AM3I/AAAAAAAAFAY/o_hQS7YPpVYDgrJgPv8jGCKSEVEuXhNEACLcBGAs/s640/Picture2.png" width="640" /></a></div>
<div>
<br /></div>
<div>
Что же хранится в этих разделах? Образ гипервизора – это файл сжатый файл s.v00, который разжимается при загрузке и содержит операционную систему гипервизора. Корневой раздел (/etc, /lib и т.д.) появляется в результате распаковки образа, таким образом, корневой раздел располагается только в оперативной памяти хоста. Возникает резонный вопрос, а как сохраняются настройки? При плановом выключении все конфиги запаковываются в файл state.tgz, который сохраняется рядом с образом гипервизора. При каждой загрузке настройки читаются из этого файла. Если завершить работу гипервизора некорректно, то все несохраненные изменения в настройках гипервизора будут утеряны. (UPD. не совсем так, см. комментарий).</div>
<h3 style="text-align: left;">
Что же изменится, если мы возьмем для установки диск объемом более 1GB (~5.2GB)?</h3>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/-6XKpgjsDbuk/WVA2wq2vneI/AAAAAAAAFAg/-uxPRO2ynGQZmxHQxypoff2OS18HotgmQCLcBGAs/s1600/Picture3.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="383" data-original-width="973" height="250" src="https://3.bp.blogspot.com/-6XKpgjsDbuk/WVA2wq2vneI/AAAAAAAAFAg/-uxPRO2ynGQZmxHQxypoff2OS18HotgmQCLcBGAs/s640/Picture3.png" width="640" /></a></div>
<div>
Мы увидим, что появятся два дополнительных раздела:</div>
<div>
<ul style="text-align: left;">
<li>Раздел #2. Раздел Scratch, содержащий разнообразные log файлы vmkernel и других компонент гипервизора.</li>
<li>Раздел #3. Весь оставшийся объем будет выделен под VMFS раздел. Он будет виден как Local Storage в vSphere Client и на нем можно будет размещать файлы виртуальных машин.</li>
</ul>
</div>
<div>
И последнее про разделы. Начиная с ESXi 5.5 был добавлен второй раздел для coredump. Самое интересное, что, если вы обновлялись до версии 5.5, то вы не найдете этот раздел, он не будет существовать. Он будет создан только при чистой установке ESXi (<a href="http://www.virtuallyghetto.com/2014/06/two-coredump-partitions-in-esxi-5-5.html" target="_blank">Two coredump partitions in ESXi 5.5?</a>).</div>
<div>
Связано это с тем, что объем оперативной памяти, установленный в сервера растет, и раздел объемом 110MB уже не способен уместить coredump современного сервера.</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-ttcDQYiFEAE/WVA3Id0NX1I/AAAAAAAAFAk/iME0M0SG2NM5vTBcpY-NmzhizS6r1IXrACLcBGAs/s1600/Picture4.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="314" data-original-width="973" height="206" src="https://4.bp.blogspot.com/-ttcDQYiFEAE/WVA3Id0NX1I/AAAAAAAAFAk/iME0M0SG2NM5vTBcpY-NmzhizS6r1IXrACLcBGAs/s640/Picture4.png" width="640" /></a></div>
<div>
<br /></div>
<div>
Все это мы можем увидеть и подключившись к гипервизору по SSH. Мы видим все 8 разделов на диске, размеры этих разделов соответствуют написанному выше.</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://2.bp.blogspot.com/-1U1UxJqrdyU/WVA3QYk7qnI/AAAAAAAAFAo/Oa0wSvp_4UQslv5vZrpAAlVUtpGeR1QTgCLcBGAs/s1600/Picture5.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="548" data-original-width="973" height="360" src="https://2.bp.blogspot.com/-1U1UxJqrdyU/WVA3QYk7qnI/AAAAAAAAFAo/Oa0wSvp_4UQslv5vZrpAAlVUtpGeR1QTgCLcBGAs/s640/Picture5.png" width="640" /></a></div>
<div>
Так же мы можем увидеть, что разделы altbootbank, bootbank, scratch и store смонтированы в соответствующие папки файловой системы.</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-aWtOgrdLXAY/WVA3jzHtFWI/AAAAAAAAFAs/nad_jteb63wj2VgDW27K-Z18-5dJ2NrEwCLcBGAs/s1600/Picture6.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="530" data-original-width="972" height="348" src="https://4.bp.blogspot.com/-aWtOgrdLXAY/WVA3jzHtFWI/AAAAAAAAFAs/nad_jteb63wj2VgDW27K-Z18-5dJ2NrEwCLcBGAs/s640/Picture6.png" width="640" /></a></div>
<div>
Все вышесказанное справедливо для установки на локальный диск или SATADOM достаточного объема. Подключившись по SSH к ESXi серверу, мы можем увидеть, что ID разделов соответствуют ID смонтированных томов.</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-TPgTZ1Hc5oI/WVA3ufLQV0I/AAAAAAAAFAw/wFRQ-sJi_7oQUjme3Y9MzynpXCHt7HZ3ACLcBGAs/s1600/Picture7.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="489" data-original-width="972" height="320" src="https://4.bp.blogspot.com/-TPgTZ1Hc5oI/WVA3ufLQV0I/AAAAAAAAFAw/wFRQ-sJi_7oQUjme3Y9MzynpXCHt7HZ3ACLcBGAs/s640/Picture7.png" width="640" /></a></div>
<div>
Если мы установили ESXi на USB stick или SD card поведение гипервизора меняется. Связано это с тем, что «живучесть» (endurance) USB stick или SD card очень низкая и,, если гипервизор начнет писать свои логи на них, то он выведет их из строя очень быстро.</div>
<div>
При установке ESXi определяет тип загрузочного устройства и, если это USB stick или SD card, установщик не будет создавать Раздел #2 (Scratch), а папка Scratch будет ссылаться на /tmp/scratch. Подключившись к хосту через vSphere Client, мы увидим предупреждения, что логи сервера сохраняются на non-persistent хранилище и будут потеряны при перезагрузке.</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-WB0mSgllqPc/WVA33d9m9LI/AAAAAAAAFA0/ae9GHMbQoxc_4-WSqWg1gKoOqGAOH5o-QCLcBGAs/s1600/Picture8.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="501" data-original-width="973" height="328" src="https://1.bp.blogspot.com/-WB0mSgllqPc/WVA33d9m9LI/AAAAAAAAFA0/ae9GHMbQoxc_4-WSqWg1gKoOqGAOH5o-QCLcBGAs/s640/Picture8.png" width="640" /></a></div>
<div>
Если в системе появится локальный Storage, то при очередной перезагрузке гипервизор увидит, что логи можно писать на него. В раздел scratch будет смонтирована папка .locker, находящаяся на этом локальном Storage, а предупреждение пропадет.</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-lppO1Nt4K6I/WVA3-9k44fI/AAAAAAAAFA4/FrIDIrfHK1ICAPVJNHvsOmqf8vWCR43QwCLcBGAs/s1600/Picture9.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="452" data-original-width="974" height="296" src="https://1.bp.blogspot.com/-lppO1Nt4K6I/WVA3-9k44fI/AAAAAAAAFA4/FrIDIrfHK1ICAPVJNHvsOmqf8vWCR43QwCLcBGAs/s640/Picture9.png" width="640" /></a></div>
<div>
Как я уже писал выше, гипервизор при загрузке «живет» в памяти. Для этого используются RAM диски. RAM диск – это раздел или хранилище, находящиеся в оперативной памяти сервера, важно помнить, что при перезагрузке, все данные из RAM диска будет потеряны. Примером использования RAM диска является монтирование scratch в /tmp/scratch. С помощью команды <b>esxcli system visorfs ramdisk list</b> можно увидеть список всех RAM дисков.</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-zUsTCYnTsw0/WVA4OnBu8_I/AAAAAAAAFA8/3spMVMlx5nkm59KZSkU4GS1SuZqtYd2MwCLcBGAs/s1600/Picture10.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="444" data-original-width="981" height="288" src="https://4.bp.blogspot.com/-zUsTCYnTsw0/WVA4OnBu8_I/AAAAAAAAFA8/3spMVMlx5nkm59KZSkU4GS1SuZqtYd2MwCLcBGAs/s640/Picture10.png" width="640" /></a></div>
<h3 style="text-align: left;">
Что же такое scratch и почему я уделил так много времени ему?</h3>
<div>
Это раздел, в который гипервизор пишет все свои логи, а в случае проблем и обращении в техническую поддержку VMware, логи очень важны!</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-8jP73-2vBNs/WVA4kjawFvI/AAAAAAAAFBA/nxjEXbp2qdg_jZEAj3kClkdler7Gss9bQCLcBGAs/s1600/Picture11.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="258" data-original-width="974" height="168" src="https://4.bp.blogspot.com/-8jP73-2vBNs/WVA4kjawFvI/AAAAAAAAFBA/nxjEXbp2qdg_jZEAj3kClkdler7Gss9bQCLcBGAs/s640/Picture11.png" width="640" /></a></div>
<div>
<br /></div>
<div>
Я настоятельно рекомендую разобраться с хранение логов в вашей системе и принять меры для надежного и понятного их хранения. Для этого можно ознакомиться с KB <a href="https://kb.vmware.com/kb/1033696" target="_blank">Creating a persistent scratch location for ESXi</a>. Приведу здесь только скриншот алгоритма выбора гипервизором места хранения логов.</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-pmMp0OU4rtw/WVA42DOtFPI/AAAAAAAAFBE/wflS62WSshsVr1-FGibCqUJZqR25l_eeACLcBGAs/s1600/Picture12.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="160" data-original-width="734" height="85" src="https://4.bp.blogspot.com/-pmMp0OU4rtw/WVA42DOtFPI/AAAAAAAAFBE/wflS62WSshsVr1-FGibCqUJZqR25l_eeACLcBGAs/s400/Picture12.png" width="400" /></a></div>
<div>
<br /></div>
<div>
Отличным вариантом является использование Syslog сервера для сбора логов. Возможно у вас уже есть Syslog сервер для другого оборудования, если нет, то это хороший повод начать его использовать <a href="https://kb.vmware.com/kb/2003322" target="_blank">Configuring syslog on ESXi</a>. Например, можно использовать VMware Log Insight. Если у вас куплен vCenter, то для небольшой инфраструктуры его можно использовать бесплатно.</div>
<h3 style="text-align: left;">
С логами мы разобрались. Перейдем к coredump</h3>
<div>
Coredump как и логи является очень важным источником информации, необходимым для работы технической поддержки при расследовании инцидентов. В coredump записывается состояние системы при PSOD (при «падении» системы).</div>
<div>
Как я писал выше, начиная с ESXi 5.5 таких раздела два, мы можем увидеть это на скриншоте ниже. </div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-k4bdLvBMJ4w/WVA5PUgQb3I/AAAAAAAAFBI/BBItZEg_jQkBpnakquQY9UrbkTbSkdZUACLcBGAs/s1600/Picture13.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="307" data-original-width="973" height="200" src="https://1.bp.blogspot.com/-k4bdLvBMJ4w/WVA5PUgQb3I/AAAAAAAAFBI/BBItZEg_jQkBpnakquQY9UrbkTbSkdZUACLcBGAs/s640/Picture13.png" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/-O7zdxNdFaX0/WVA5TblWyxI/AAAAAAAAFBM/VjK2u_Vsuwg1De_ojMXj01OqsM478dw4QCLcBGAs/s1600/Picture14.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="329" data-original-width="973" height="216" src="https://3.bp.blogspot.com/-O7zdxNdFaX0/WVA5TblWyxI/AAAAAAAAFBM/VjK2u_Vsuwg1De_ojMXj01OqsM478dw4QCLcBGAs/s640/Picture14.png" width="640" /></a></div>
<div>
Настоятель рекомендую проверить coredump разделы на ваших гипервизорах и в случае необходимости внести изменения <a href="https://kb.vmware.com/kb/2004299" target="_blank">Configuring a diagnostic coredump partition on an ESXi 5.x/6.x host</a> и <a href="https://kb.vmware.com/kb/2077516" target="_blank">Configuring ESXi coredump to file instead of partition</a>.</div>
<div>
Важно заметить, что если вы используете в своей инфраструктуре ESXi хосты с объемом RAM памяти больше 512GB (и vSAN), то вам следует ознакомится с еще одной статьей из KB <a href="https://kb.vmware.com/kb/2147881" target="_blank">Extending an ESXi diagnostic coredump partition on a vSAN node</a>. Дело в том, что стандартный раздел для coredump (2.5GB) может не вместить дамп и этот раздел нужно будет увеличить.</div>
<h3 style="text-align: left;">
Появляется vSAN</h3>
<div>
vSAN приносит в нашу систему еще один набор логов - vSAN traces:</div>
<div>
<ul style="text-align: left;">
<li>vSAN traces help VMware support and engineering to understand what is going on internally with vSAN.</li>
<li>It should be noted that these traces are *not* part of syslog.</li>
<li>So if you setup a syslog server to capture VMkernel logs, you will not capture vSAN traces.</li>
<li>vSAN trace files are not persisted with syslog because the bandwidth requirements are too high. (Although with vSAN 6.2, we now persist just the “most important” traces along with syslog https://kb.vmware.com/kb/2145556).</li>
</ul>
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-sp5zH5BzGmQ/WVA6DQq012I/AAAAAAAAFBU/Q3KJAxfC1Mg60cpYsViVhBkH3s4AGDtkQCLcBGAs/s1600/Picture15.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="404" data-original-width="974" height="264" src="https://4.bp.blogspot.com/-sp5zH5BzGmQ/WVA6DQq012I/AAAAAAAAFBU/Q3KJAxfC1Mg60cpYsViVhBkH3s4AGDtkQCLcBGAs/s640/Picture15.png" width="640" /></a></div>
<div>
И теперь необходимо заботиться о сохранности еще одного набора логов.</div>
<div>
Что важно для нас, что vSAN traces ведут сябя аналогично scratch и если мы установили гипервизор на USB stick или SD card, то traces будут писаться в RAM диск и пропадут при перезагрузке.</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://2.bp.blogspot.com/-Ky48_FfFVQQ/WVA6NpbkAnI/AAAAAAAAFBY/mnL1ryEW4W4-tvyhu4V-9EBAGjNyfyOJgCLcBGAs/s1600/Picture16.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="520" data-original-width="974" height="340" src="https://2.bp.blogspot.com/-Ky48_FfFVQQ/WVA6NpbkAnI/AAAAAAAAFBY/mnL1ryEW4W4-tvyhu4V-9EBAGjNyfyOJgCLcBGAs/s640/Picture16.png" width="640" /></a></div>
<div>
<br /></div>
<div>
Так как vSAN traces очень важны для восстановления данных при сбое, то при штатной перезагрузки наиболее важные из них записываются на персистентное хранилище:</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-HljCrkxUS5Y/WVA6WzbiSWI/AAAAAAAAFBc/DHCamYvI1y47rEEW0i4m1gRO6g8ba-94ACLcBGAs/s1600/Picture17.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="510" data-original-width="757" height="430" src="https://1.bp.blogspot.com/-HljCrkxUS5Y/WVA6WzbiSWI/AAAAAAAAFBc/DHCamYvI1y47rEEW0i4m1gRO6g8ba-94ACLcBGAs/s640/Picture17.png" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://2.bp.blogspot.com/-3hMyrQpPoi8/WVA6eoauM7I/AAAAAAAAFBg/OtrBui406sYXRGwnRXgnpRWCeLl5Z_0GQCLcBGAs/s1600/Picture18.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="599" data-original-width="974" height="392" src="https://2.bp.blogspot.com/-3hMyrQpPoi8/WVA6eoauM7I/AAAAAAAAFBg/OtrBui406sYXRGwnRXgnpRWCeLl5Z_0GQCLcBGAs/s640/Picture18.png" width="640" /></a></div>
<h2 style="text-align: left;">
<span style="text-align: left;">Здесь должны быть выводы</span></h2>
<div>
<ol style="text-align: left;">
<li>У вас должен (обязан) быть syslog сервер и чем больше на него будет перенаправлено логов, тем легче будет увидеть корреляцию при сбоях. Отличной практикой является перенаправлять логи и серверов и сетевого оборудования и СХД на один syslog сервер. Это позволит вам сразу увидеть, что, например, сбой коммутатора повлек проблемы на виртуальной платформе.</li>
<li>Нужно быть внимательным с выбором загрузочного устройства для ESXi и помнить, что не все устройства одинаково полезны.</li>
<li>Еще раз перепроверить, что логи записываются на какое-то постоянное хранилище и к ним можно получить доступ.</li>
<li>Аналогично про coredump, перепроверить, что раздел для записи дампа существует, и он подходящего для хоста объема.</li>
<li>И раз я писал про vSAN, не могу не упомянуть, что все оборудование хоста должно быть в <a href="https://www.vmware.com/resources/compatibility/search.php" target="_blank">VMware Compatibility Guide</a>, включая версии firmware и версии драйверов.</li>
</ol>
</div>
</div>
<div class="blogger-post-footer"><br/>--
<br/><a href="http://blog.vadmin.ru">http://blog.vadmin.ru</a> - Записки виртуального админа</div>Grigory Pryalukhinhttp://www.blogger.com/profile/06924576956173428091noreply@blogger.com3tag:blogger.com,1999:blog-5320167098569797652.post-43798559985503282852017-06-24T18:27:00.000+03:002017-06-24T18:27:12.008+03:00Ограничивать ли пользователей по ресурсам?<div dir="ltr" style="text-align: left;" trbidi="on">Сколько я занимаюсь ИТ - столько я слышу от админов "больно жирно будет пользователям, обрежем им трафик / объем почтового ящика / файловую шару / заблокируем сайт / подставить по вкусу". И ровно столько же у меня возникает вопрос: какое ваше дело?<br />
Давайте забудем, что мы ИТ-шники и управляем клевыми СХД, фермами серверов, поточвыми серверами и посмотрим на всю это катавасию отстраненно. Рассмотрим коммерческую структуру.<br />
<br />
<b>1. Чем занимается ваша компания?</b><br />
<br />
Забудьте про производство туалетной бумаги, штанов или даже авиадвигателей.<br />
Правильный ответ: она производит деньги. Причем так, чтобы произведенных денег получалось больше, ченм потраченных.<br />
<br />
<b>2. Кто производит деньги?</b><br />
<br />
А их производят те самые "тупые юзвери", которые просят нажать any key великого и могучего техномага. Даром что техномаг настолько велик, что не может читать инструкции на английском (рабочем языке ИТ), а для русского он и так слишком велик.<br />
<b><br />
3. При помощи чего они производят деньги?<br />
</b><br />
Деньги производятся в том числе при помощи ИТ сервисов, включая почтовые серверы для коммуникации с клиентами, интернета, систем учета, бухгалтерии и т.д. В процессе производства денег ИТ сервисы потребляют ИТ ресурсы - сырые мощности (процессоры / ОЗУ / СХД), лицензии, каналы.<br />
<br />
<b>4. Кому принадлежит ИТ инфраструктура и ресурсы?</b><br />
<br />
Вот здесь раз от раза я натыкаюсь на то, что администраторы начинают считать серверы, СХД и коммутаторы "своими". Даже немного, и начинают относиться к ним соответственным образом.<br />
<br />
Правильный ответ: они принадлежат компании (владельцу компании) и должны исполнять свою задачу по генерации денег.<br />
<br />
<b>5. И теперь - кто должен решать, сколько ресурсов может потребить сотрудник бизнес подразделения?</b><br />
<br />
Как мне кажется, это абсолютно точно не должен быть ИТ админ. Просто потому что он понятия не имеет о том, как эти ресурсы приносят деньги.<br />
Потребление ресурсов должно быть неограниченным со стороны ИТ, с практически нулевым весом ИТ в принятии решения о выделении ресурсов на ИТ инфраструктуре. Кроме разве что моментов, когда внезапный рост потребления может положить всю инфраструктуру целиком.<br />
<br />
Необходима система внутреннего биллинга, которая вместо ограничения потребления попросту присылает в конце месяца счет начальнику отдела и фин. директору о том, кто сколько и каких ресурсов потребил. В рублях. Просто потому что именно эти два человека понимают какую доли прибыли генерирует данный сотрудник и сколько ему надо ресурсов для генерации этой прибыли.<br />
<br />
Вы конечно можете возразить сразу по нескольким пунктам. Давайте их рассмотрим.<br />
<b><br />
1. Если не ограничивать соц. сети, то вместо работы все будут только во вконтактике сидеть.</b><br />
<br />
Может быть. Но разве это ваша сфера ответственности и знаний? У сотрудника есть начальник, который оценивает качество его работы. Может быть, конечно, именно начальник попросит обрезать Ивану Ивановичу Иванову доступ к соц. сетям - но это его сфера принятия решения. Может быть это будет политика ИБ, но опять же, это не решение админа.<br />
<br />
<b>2. Они безмозглые и ничего не понимают в ИТ. И совсем не думают, что их смешные картинки и видюшки в почтовых вложениях полностью съедят СХД под почту.</b><br />
<br />
Ну на то и есть вы, мозглые и понимающие. Только вот есть снова интересный момент, ничего не воспитывает человека так быстро и эффективно, как воздействие на его кошелек. Один раз остаться всем отделу маркетинга без премии потому что они 90% потребленного пространства в почте потратили на картинки - и их компьютерная грамотность / здравый смысл резко повысятся. А самое главное, стимулировать их повышение будет родными и понятными методами начальник отдела, оставшийся без премии. Вся их премия уйдет на расширение СХД.<br />
<br />
<b>3. У нас в ИТ ограниченный бюджет и мы не можем позволить им есть ресурсов сколько они хотят.</b><br />
<br />
Позвольте, но это классический пример "административная проблема техническими средствами не решается". Проблема с планированием бюджета / экономическим обоснованием закупок в классической модели - это административная проблема на уровне директората, а не админа. Более того, при помощи биллинга вопрос обоснования бюджетов решается сильно проще.<br />
Есть и другая сторона ограничения ресурсов. Вы перестаете контролировать что происходит в компании. Пользователи начинают удалять важную на самом деле почту, потому что новую не могут получить. Важные документы оказываются в облаках, переписка перемещается с корпоративной почты в Яндекс и Мейл.ру. Иными словами, именно слепой репрессивный метод является создателем "теневого ИТ".<br />
<br />
И да, это все я рассказываю с 2014 года. <a href="http://blog.vadmin.ru/2015/08/blog-post.html">"Департамент ИТ против частного облака"</a><br />
<br />
</div><div class="blogger-post-footer"><br/>--
<br/><a href="http://blog.vadmin.ru">http://blog.vadmin.ru</a> - Записки виртуального админа</div>Anton Zhbankovhttp://www.blogger.com/profile/00989828695484228304noreply@blogger.com5tag:blogger.com,1999:blog-5320167098569797652.post-27530475696054413142017-02-09T02:01:00.000+03:002017-02-09T02:01:57.323+03:00OpenStack как религиозная секта<div dir="ltr" style="text-align: left;" trbidi="on">После 14 лет работы с виртуальными машинами, и 10 лет работы с промышленными платформами виртуализации я решил разобраться в OpenStack. Вокруг только и разговоров о нем. VMware больше не нужна, VMware скоро умрет и останется только OpenStack. Но по мере знакомства со всем стеком и с сообществом все больше у меня появлялась убежденность, что я имею дело с сектой.<br />
<br />
OpenStack - технология, перечеркивающая и противопоставляющая себя привычным подходам и продуктам. Для всего изобретается свой, особый, православный подход. Зачастую (причем скорее как правило) деятели, связанные с OpenStack - люди достаточно асоциальные даже по меркам обычных ИТ-шников. В абсолютном большинстве случаев поклонник OpenStack видит лишь один правильный путь - OpenStack. Остальные пути и технологии считаются заведомо недостойными изучения ересями.<br />
<br />
В рамках OpenStack существует свой, отдельный язык. Забудьте про сеть - это Neutron. Забудьте про систему хранения - это Cinder. Вся индустрия уже многие годы использует примерно устоявшиеся термины, и после VMware начать изучать Hyper-V не составит значительного труда. В случае с OpenStack надо начать с изучения нового языка, что еще раз подчеркивает раскол между "обычными" и "просветленными".<br />
<br />
В рамках проектов по OpenStack приверженцы технологии неспособны к самокритике и здравой оценке ситуации. Провальные проекты - это всегда вина недостаточно веровавших в них заказчиков. Пропало несколько тысяч виртуальных машин - OpenStack не может быть виноват. Всегда виноват конечный потребитель.<br />
<br />
При разговоре речь идет не о технологиях, она ведет о вере. "Ты должен верить" - прямая цитата одного из известных на рынке деятелей.<br />
<br />
HP увольняет команду разработки OpenStack, Мирантис сокращает треть сотрудников. Ну и что, это же не имеет отношения к вере в.<br />
<br />
Встречая любителя OpenStack на любом форуме, задумайтесь о его аргументации. Она сбивчивая, постоянная апелляция к неведомому "прогрессивному" человечеству и полное игнорирование реалий индустрии. TCO? Риски? Стоимость поддержки? Из всех аргументов можно услышать только "бесплатно" и "зато я могу допилить под себя". Ему не нужны успешные проекты, ему не нужны реальные результаты, это просто вербовка новых адептов в новую, измененную реальность.<br />
<br />
Основа сообщества OpenStack - преимущественно "техногики", люди, которые слабо разбираются в глубоких технических моментах, но очень любят модную технологическую шумиху и обожают рассуждать/вариться в ней. Техногики сейчас практически везде и именно им надо сказать спасибо за проталкивание маркетинговых идей, которые не выдерживают никаких технических аргументов. Собственную техническую неграмотность техногики прикрывают лозунгом о мифической силе «сообщества» и миллионами глаз, которые теоретически найдут ошибку в открытых кодах.<br />
<br />
К вниманию также предлагаются <a href="https://www.facebook.com/anton.zhbankov/posts/874517942609354">перлы докладчиков с OpenStack Day в 2015</a>. <br />
</div><div class="blogger-post-footer"><br/>--
<br/><a href="http://blog.vadmin.ru">http://blog.vadmin.ru</a> - Записки виртуального админа</div>Anton Zhbankovhttp://www.blogger.com/profile/00989828695484228304noreply@blogger.com2tag:blogger.com,1999:blog-5320167098569797652.post-79743187797330850742017-02-02T18:10:00.000+03:002017-02-02T18:10:12.841+03:00Highload 2016. Что уже умеют промышленные СХД. Видео<div dir="ltr" style="text-align: left;" trbidi="on"><br />
Друзья, по многочисленным просьбам выкладываю видеозапись доклада, скажем спасибо за нее организаторам!<br />
<br />
<iframe width="560" height="315" src="https://www.youtube.com/embed/aToZMenqaPU" frameborder="0" allowfullscreen></iframe><br />
<br />
</div><div class="blogger-post-footer"><br/>--
<br/><a href="http://blog.vadmin.ru">http://blog.vadmin.ru</a> - Записки виртуального админа</div>Anton Zhbankovhttp://www.blogger.com/profile/00989828695484228304noreply@blogger.com2tag:blogger.com,1999:blog-5320167098569797652.post-17439174745172492772016-12-07T21:05:00.000+03:002016-12-12T13:03:46.200+03:00nBeers Engineers 2016-1Коллеги, мы решили сделать маленькое теплое и ламповое мероприятие в неформальном стиле.<br />
<br />
nBeers Engineers - чтобы ИТ-инженеры, архитекторы и мастера на все руки могли пообщаться за кружечкой пива.<br />
А мы в процессе заодно расскажем и даже покажем нашу новую версию Nutanix OS 5.0 Asterix.<br />
<br />
13 декабря с 18-30 в баре "<a href="https://www.facebook.com/pboroda/">Пес Борода</a>" (метро Трубная, ул. Трубная 15)<br />
<br />
Поскольку мероприятие будет только для своих и бар полностью закроется для обычных посетителей, большая просьба заранее зарегистрироваться.<br />
<br />
Регистрация закрыта.<div class="blogger-post-footer"><br/>--
<br/><a href="http://blog.vadmin.ru">http://blog.vadmin.ru</a> - Записки виртуального админа</div>Anton Zhbankovhttp://www.blogger.com/profile/00989828695484228304noreply@blogger.com0tag:blogger.com,1999:blog-5320167098569797652.post-48299565780837018122016-11-13T02:21:00.000+03:002016-11-13T02:21:06.540+03:00Highload 2016. Что уже умеют промышленные СХД.<iframe src="//www.slideshare.net/slideshow/embed_code/key/mESKDJZa4bSoCe" width="595" height="485" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe> <div style="margin-bottom:5px"><strong> <a href="//www.slideshare.net/profyclub_ru/nutanix-68709831" title="Велосипед уже изобретен. Что умеют промышленные СХД? / Антон Жбанков (Nutanix)" target="_blank">Велосипед уже изобретен. Что умеют промышленные СХД? / Антон Жбанков (Nutanix)</a> </strong> from <strong><a target="_blank" href="//www.slideshare.net/profyclub_ru">Ontico</a></strong> </div><div class="blogger-post-footer"><br/>--
<br/><a href="http://blog.vadmin.ru">http://blog.vadmin.ru</a> - Записки виртуального админа</div>Anton Zhbankovhttp://www.blogger.com/profile/00989828695484228304noreply@blogger.com4tag:blogger.com,1999:blog-5320167098569797652.post-29010572972779092452016-10-18T16:27:00.002+03:002016-10-20T14:32:45.268+03:00VMworld EU 2016<div dir="ltr" style="text-align: left;" trbidi="on">
<b>STO8165</b>, John Nicholson (<a href="https://twitter.com/Lost_Signal" target="_blank">@Lost_Signal</a>)<br />
VSAN Networking Deepdive<br />
<br />
* Используйте мультикаст флад только для выделенных под VSAN VLANов<br />
* Если у вас несколько кластеров VSAN в одном VLAN - поменяйте им мультикаст адреса, чтобы каждый кластер имел свой уникальный. Или разнесите по разным VLAN<br />
* Не делайте VSAN поверх L3 если не уверены зачем это делаете<br />
* Для больших и нагруженных кластеров VSAN очень чувствителен к степени переподписки аплинков. В качестве средней температуры можно взять 4 к 1, но для каждого случая надо смотреть конкретнее<br />
* Идеальный вариант коммутаторов для VSAN - со связями запад-восток. Осторожнее с Cisco FEX - там все через аплинк<br />
* Jumbo frames не имеют большого значения для VSAN<br />
* Локализация ввода-вывода (data locality) не имеет большого смысла для VSAN, ведь каждая запись должна все равно идти через сеть. /* Nutanix смотрит на это утверждение с удивлением.<br />
* Начиная с 6.5 поддерживаются микрокластеры из двух узлов с прямым подключением между узлами (кросс-кабелем).<br />
* Растянутый кластер требует VSAN Enterprise и поддерживается с сетями 10G 5ms RTT. 1 Гбит в целом поддерживается, но не рекомендуется.<br />
* Для растянутого кластера требуется cluster witness. Он может быть виртуальной машиной или ESXi хостом (для него не требуется лицензия). Сетевое подключение - не менее 100 мегабит. /* Nutanix снова смотрит с удивлением, обходясь 2 мегабитами.<br />
* Дедупликация идет фиксированными блоками 4 кб для All-Flash. Гибридный VSAN не поддерживает дедупликацию. /* Nutanix махнул рукой, ушел<br />
<br />
<b>INF8701</b>, Brett Guarino<br />
vSphere Core 4 Performance Troubleshooting and Root Cause Analysis, Part 2: Disk and Network<br />
<br />
* VMXNET драйвер работает в ring 1, E1000 - ring 2<br />
* Почти все сводится к esxtop<br />
* Хотите при помощи esxtop анализировать сеть? Купите БОЛЬШОЙ монитор<br />
* Ключевые показатели при анализе сети в vSphere<br />
- используемые физические аплинки для каждого vmnic<br />
- фактическая скорость на vmnic<br />
- счетчик пакетов и средний размер пакета на vmnic<br />
- отброшенные пакеты на vmnic<br />
- фактическая скорость на физическом интерфейсе<br />
- счетчик пакетов и средний размер пакета на физическом интерфейсе<br />
- отброшенные пакеты на физическом интерфейсе<br />
* Исследование дисковой системы - это куда больше веселья, чем сети :)<br />
* Ключевые показатели - IOPS, задержки и фактическая скорость в мегабайтах в секунду<br />
* Ситуации с DAVG/KAVG:<br />
- низкий/низкий - идеально<br />
- низкий/высокий - перегруженный хост<br />
- высокий/низкий - перегруженная СХД<br />
- высокий/высокий - проблема и там, и там. Но иногда слишком перегруженная СХД ведем к перегрузке дискового стека хоста.<br />
** остаток доклада по дисковой системе фактически повторяет мою презентацию на VMUG 2014 в упрощенном виде. (<a href="http://blog.vadmin.ru/2014/06/vmug-2014.html">http://blog.vadmin.ru/2014/06/vmug-2014.html</a>)<br />
<div>
<br /></div>
<b><br /></b>
<b>VIRT8530</b>, Rob Girard, Shawn Meyers<br />
Deep Dive on pNUMA and vNUMA - Save Your SQL VMs from Certain DoomA!<br />
<br />
* SQL не очень работает на AMD NUMA. Ставьте Intel. /* речь, разумеется, о широких SQL<br />
* Неправильная конфигурация NUMA может вести к падению производительности до 40%<br />
* По умолчанию vNUMA включается только при 9+ vCPU ВМ.<br />
- Если у вас 4 или 6-ядерные процессоры и ВМ с большим количеством vCPU, чем ядер на процессоре - у вас будут проблемы с NUMA<br />
- Можно исправить при помощи <i>numa.min.vcpu</i> для ВМ<br />
* Лучший сайзинг ВМ - это много сокетов по 1 ядру. В этом случае автоматика отработает и ситуация будет близка к идеальной<br />
- как только вы измените количество ядер на отличное от 1, конфигурация vNUMA зафиксируется<br />
- vSphere определит топологию NUMA на первой загрузке. Это фиксируется в .vmx<br />
- Используйте более одного ядра на сокет только для приложений с лицензированием по сокетам<br />
- Если вы уверены в том, что делаете - сделайте сайзинг по границам узлов<br />
* Идеальный сайзинг ВМ по vCPU - число, кратное одному узлу NUMA. Т.е. для 12-ядерного узла это 1, 2, 3, 4, 6, 12. На практике 3 vCPU ВМ работает на 6-ядерном процессоре лучше, чем 4vCPU.<br />
* vSphere 6.5 позволяет сделать двойной финт - обмануть приложение по лицензированию, и при этом технически использовать автосайзинг NUMA<br />
- <i>numa.vcpu.followcorespersocket </i>= 0 (по умолчанию)<br />
- если установить в 1, то вернется старое поведение<br />
* Расширенные настройки. !!! Опасно !!! Только если вы действительно понимаете что делаете<br />
- <i>numa.vcpu.maxPerVirtualNode</i> = 8 (по умолчанию) - для расширения ВМ на дополнительные NUMA узлы<br />
- <i>numa.vcpu.preferHT</i> = False (по умолчанию) - использовать потоки HT вместо дополнительных узлов NUMA. Для некоторых нагрузок важнее остаться в пределах одного узла.<br />
- <i>numa.vcpu.min</i> = 9 (по умолчанию) - когда vNUMA начинает использоваться<br />
- <i>numa.autosize</i> = False (по умолчанию) - пересчитывать топологию NUMA каждый раз при загрузке ВМ. Рекомендуется в True.<br />
- <i>numa.autosize.once</i> = True (по умолчанию) - рассчитывать топологию NUMA при первой загрузке ВМ. Рекомендуется в False.<br />
- <i>numa.autosize.cookie</i> = [автогенерируемое] - автоконфигурация vNUMA. 160001 = 16 сокетов, 1 ядро<br />
- <i>numa.autosize.vcpu.maxPerVirtualNode</i> = [автогенерируемое] - сколько ядер на каждый узел NUMA при автосайзинге.<br />
* Если в .vmx присутствуют <i>numa.autosize.vcpu.maxPerVirtualNode</i> или <i>cpuid.coresPerSocket </i>- автосайзинг не используется<br />
* CPU HotAdd для виртуальной машины отключает vNUMA<br />
* Memory HotAdd работает по разному<br />
- HW ver 8-10 добавляет память в vNUMA node 0, что приводит к дисбалансу<br />
- HW ver 11 балансирует память между vNUMA узлами<br />
* Настройки vNUMA на уровне хоста в абсолютном большинстве случаев НЕ НАДО трогать.<br />
* Перед тем как винить vNUMA проверьте все остальное.<br />
* Не делайте 4-сокетную ВМ на 2-сокетном сервере. </div>
<div class="blogger-post-footer"><br/>--
<br/><a href="http://blog.vadmin.ru">http://blog.vadmin.ru</a> - Записки виртуального админа</div>Anton Zhbankovhttp://www.blogger.com/profile/00989828695484228304noreply@blogger.com3tag:blogger.com,1999:blog-5320167098569797652.post-24456034198518017492016-07-04T11:40:00.000+03:002016-07-04T12:42:33.477+03:00What will virtualization look like in 10 years?Let's define "virtualization" for the start. Virtualization is abstraction from hardware itself, hardware microarchitecture. So, when we talk about virtualizion - it's not just about server hypervisors and VMware virtual machines. Software defined storage, containers, even remote desktops and application streaming - all of these are virtualization technologies.<br />
<br />
As of today, mid of 2016, server virtualization is almost stalled in progress. No breakthroughs for last several years. Honing hypervisors for perfection, challengers follow the lead and difference is less and less with each year. So vendors fight now in the ecosystem - management, orchestrators, monitoring tools and subsystems integration. We are now surprised when someone wants to buy a physical server and install Windows on it instead of hypervisor. Virtual machines are no longer an IT toys, it's an industrial standard. Unfortunately sensible defense <br />
scheme (from backups to virtualization-aware firewalls) is not yet standard feature.<br />
<br />
Software Defined Everything, or we can say Virtualized Everything, grow enormously. Most of the corporate level storage systems are almost indistinguishable from standard x86 servers except of form factor. Vendors do not use special CPUs or ASICs anymore, putting powerful multicore Xeons in controllers instead. Storage system of today is actually just a standard server with standard hardware, just with a lot if disks and some specialized software. All the storage logic, RAIDs, replication and journaling is in software now. We blur the storage/server border even more with smart cache drivers and server side flash caches. Where the server ends and storage begins?<br />
<br />
From other side we see pure software storage systems, never sold as hardware, which do not have hardware storage heritage and architecture traits. Take any server, put some disks and RAM as you please, install an application and voila! You lack space, performance or availability? Take another server, and another and maybe a couple more. It begins to look even more interesting when we install storage software in virtual machine or even make it a hypervisor module. There are no servers and storage apart - this is a computing/storage unified system. Hyperconverged infrastructure we call it. Virtual machines are running inside, virtual desktops and servers. More than that, users can not tell if they're in dedicated VM or terminal server session or is just a streamed application. But who cares when you can connect from MacDonalds just across a globe?<br />
<br />
Today we talk about containers, but it's not a technological breakthrough. We knew about them for years, especially ISPs and hosting providers. What will happen in near future - is a merge of traditional full virtualization and containers in a single unified hypervisor. Docker and their rivals are not yet ready for production level corporate workloads. Still a lot of questions in security and QoS, but I bet it's just a matter of couple of years. Well, maybe more than a couple, but 10 is more than enough. Where was VMware 10 years ago and where are we now in terms of server virtualization?<br />
Network control plane is shifting more and more towards software, access level switching blurs more and more. Where is your access level when you have 100 VMs switching inside a hypervisor never reaching physical ports? The only part really left for specialized hardware is high speed core switches or ultra-low latency networks like Infiniband. But still, this is just a data plane, control plane lives in the Cloud.<br />
<br />
Everything is moving towards the death of general OS as we know them. We don't really need an OS actually, we only need it to run applications. And applications are more and more shifting from installable to portable containers. We'll see hypervisor 2.0 as new general OS and further blur between desktop, laptop, tablet and smartphone. We still install applications, but we already store our data in the cloud. In 10 years container with application will be moving between desktop, smartphone and server infrastructure as easy as we move now virtual machines.<br />
<br />
Some years ago we had to park floppy drive heads after we're finished, teenagers of today live with cloud, teenagers of tomorrow will have to work hard to realize what is application/data link to hardware.<div class="blogger-post-footer"><br/>--
<br/><a href="http://blog.vadmin.ru">http://blog.vadmin.ru</a> - Записки виртуального админа</div>Anton Zhbankovhttp://www.blogger.com/profile/00989828695484228304noreply@blogger.com0tag:blogger.com,1999:blog-5320167098569797652.post-44555514773716377752016-06-27T15:57:00.000+03:002016-06-27T15:57:25.511+03:00Что ждет средства виртуализации через 10 лет?Для начала хочется определить понятие «средства виртуализации». Виртуализация по сути представляет собой абстрагирование от аппаратных средств, от их микроархитектуры. Поэтому говоря о средствах виртуализации, следует понимать, что это далеко не только серверная виртуализация и виртуальные машины VMware. Программно-определяемые СХД, контейнерные технологии, удаленные рабочие столы и потоковая доставка приложений – это тоже виртуализация.<br />
<br />
В середине 2016 года серверная виртуализация практически остановилась в развитии. Никаких прорывных технологий уже не ожидается, постепенно уравниваются по возможностям гипервизоры. Битва между поставщиками происходит уже в средствах мониторинга и управления, интеграции со смежными подсистемами. Покупка физических серверов и установка на них скажем Windows уже вызывает удивление, это редкость. Мы уже привыкли к виртуальным машинам, это уже индустриальный стандарт. К сожалению пока еще не является индустриальным стандартом продуманная концепция защиты - начиная от правильно построенной системы резервного копирования и заканчивая умным антивирусом и файрволлами, понимающими про виртуализацию.<br />
<br />
Все более набирает обороты концепция <i>Software Defined Everything</i>, программно-определяемое все или, по сути, виртуализованное все. Большинство корпоративных СХД уже практически ничем не отличаются от серверов, кроме форм-фактора исполнения. Производители уже отказались от специальных процессоров, все крутится на x86. Все больше производителей отказываются от сопроцесоров и специализированных ASIC'ов, перекладывая задачи на могучие Intel Xeon последних поколений. Современная СХД корпоративного класса уже по сути является стандартным сервером со стандартным оборудованием, просто с большим количеством жестких дисков. Вся логика в программном обеспечении. Граница между серверами и СХД размывается еще сильнее при помощи умных драйверов, управляющих содержимым кэш-памяти, и флэш-кэшами, устанавливаемыми в серверы. Где кончается сервер-потребитель и начинается СХД?<br />
<br />
С другой стороны наступают чисто программные СХД, не имеющие архитектурного наследства аппаратных. Возьми любой сервер стандартной архитектуры, поставь столько дисков и памяти, сколько считаешь нужным, а дальше просто поставь софт в качестве обычного приложения. Не хватает производительности, пространства, отказоустойчивости? Добавь еще один сервер, потом еще один, и сколько тебе нужно. Еще интереснее становится, когда этот софт мы устанавливаем в виртуальные машины или делаем частью гипервизора. Вычислительная система и система хранения теперь неразличимы, они одно целое - <i>гиперконвергентная </i>система. А внутри работают виртуальные серверы и виртуальные десктопы. Причем пользователи сами не понимают, работают они в выделенной виртуальной машине или в сессии терминального сервера. На виртуальные десктопы доставляются потоковые приложения, к десктопу можно подключаться с планшета из МакДональдса или из пробки на дороге через мобильный интернет, или из гостиницы через половину земного шара.<br />
<br />
Идет постепенное принятие всей индустрией ИТ давно известной среди хостинг-провайдеров технологии <i>контейнерной виртуализации</i>. В дальнейшем мы будем наблюдать слияние в единой системе и платформе как полной виртуализации, так и контейнерной. Новые и модные контейнеры Docker и сопутствующие им не готовы для работы в корпоративном секторе – недостаточно проработаны вопросы обеспечения качества обслуживания, информационной безопасности, но нет никаких сомнений в их готовности через 10 лет.<br />
Уровень управления сетью все больше перемещается в программный, размывается сетевой уровень доступа – ну а что ему еще делать при коммутации внутри гипервизора под сотню ВМ? Единственным прибежищем аппаратных специализированных архитектур будут оставаться высокоскоростные терабитные коммутаторы уровня ядра сети или специализированные коммутаторы со сверхнизкими задержками, как например Infiniband. Но и у тех останется уровень данных и сверхскоростные матрицы коммутации, в то время как уровень управления будет жить в облаке.<br />
<br />
Все идет к смерти ОС общего назначения, как мы их знаем. Ведь по сути нам не нужна ОС, нам нужны лишь приложения, а они все больше и больше виртуализуются и упаковываются в контейнеры. Вместо ОС нас ждет гипервизор нового поколения. Что в конечном итоге выльется в полное размытие понятия «персональный компьютер» - это будет и планшет, и десктоп, и даже смартфон. Сегодня мы все еще устанавливаем приложение и привязываем его к ОС, хотя данные все чаще храним в облаке. Но через 10 лет можно быть уверенным, что контейнер с приложением будет просто мигрировать между этими устройствами так же легко, как сейчас между серверами переезжает виртуальная машина.<br />
<br />
Мы когда то парковали головки флоппи-дисководов после работы, сегодняшние школьники работают с облаками. Завтрашние школьники не будут понимать – как это, есть привязка приложения и данных к устройству.<div class="blogger-post-footer"><br/>--
<br/><a href="http://blog.vadmin.ru">http://blog.vadmin.ru</a> - Записки виртуального админа</div>Anton Zhbankovhttp://www.blogger.com/profile/00989828695484228304noreply@blogger.com3tag:blogger.com,1999:blog-5320167098569797652.post-5594342663195765972016-06-22T14:11:00.000+03:002016-06-22T15:40:10.455+03:00Дизайн VDC. Расчет системы хранения<b>Расчет классической СХД по производительности</b><br />
<br />
Классическая СХД всегда рассчитывается по худшему варианту (worst case scenario), исключая влияние оперативного кэша и оптимизации операций.<br />
В качестве базовых показателей производительности принимаем механическую производительность с диска (IOPSdisk):<br />
- 7.2k – 75 IOPS<br />
- 10k – 125 IOPS<br />
- 15k – 175 IOPS<br />
<br />
Далее количество дисков в дисковом пуле рассчитывается по следующей формуле: <i>= TotalIOPS * ( RW + (1 –RW) * RAIDPen) / IOPSdisk</i>. Где:<br />
- <i>TotalIOPS</i> – суммарная требуемая производительность в IOPS с дискового пула<br />
- <i>RW</i> – процентная доля операций чтения<br />
- <i>RAIDpen</i> – RAID penalty для выбранного уровня RAID<br />
<br />
Подробнее об устройстве RAID и RAID Penalty рассказывается здесь -<a href="http://blog.vadmin.ru/2011/08/blog-post.html"> Производительность СХД. Часть первая.</a> и <a href="http://blog.vadmin.ru/2011/08/blog-post_18.html">Производительность СХД. Часть вторая.</a> и <a href="http://blog.vadmin.ru/2011/09/blog-post.html">Производительность СХД. Часть третья</a><br />
<br />
Исходя из полученного количества дисков рассчитываются возможные варианты, удовлетворяющие требованиям по емкости хранения, включая варианты с многоуровневым хранением.<br />
Расчет систем с использованием SSD в качестве уровня хранения рассматривается отдельно.<br />
<b><br />
Особенности расчета систем с Flash Cache<br />
</b><br />
<i>Flash Cache</i> – общее название для всех фирменных технологий использования флэш-памяти в качестве кэша второго уровня. При использовании флэш кэша СХД как правило рассчитывается для обеспечения с магнитных дисков установившейся нагрузки, в то время как пиковую обслуживает кэш.<br />
При этом необходимо понимать профиль нагрузки и степень локализации обращений к блокам томов хранения. Флэш кэш – технология для нагрузок с высокой локализацией запросов, и практически неприменима для равномерно нагруженных томов (как например для систем аналитики). <br />
<br />
<b>Расчет гибридных систем low-end / mid-range</b><br />
<br />
Гибридные системы нижнего и среднего классов используют многоуровневое хранение с перемещением данных между уровнями по расписанию. При этом размер блока многоуровневого хранения у лучших моделей составляет 256 МБ. Данные особенности не позволяют считать технологию многоуровневого хранения технологией повышения производительности, как ошибочно считается многими. Многоуровневое хранение в системах нижнего и среднего классов – это технология оптимизации стоимости хранения для систем с выраженной неравномерностью нагрузки.<br />
<br />
Для многоуровневого хранения рассчитывается прежде всего производительность по верхнему уровню, в то время как нижний уровень хранения считается лишь вносящим недостающую емкость хранения. Для гибридной многоуровневой системы обязательно использование технологии флэш кэша для многоуровневого пула с целью компенсации просадки производительности для внезапно нагревшихся данных с нижнего уровня.<br />
<br />
<b>Использование SSD в многоуровневом дисковом пуле</b><br />
<br />
Использование SSD в многоуровневом дисковом пуле имеет вариации, в зависимости от особенностей реализации алгоритмов флэш кэша у данного производителя.<br />
Общая практика политики хранения для дискового пула с SSD уровнем - SSD first.<br />
<i>Read Only Flash Cache.</i> Для флэш кэша только на чтение уровень хранения на SSD появляется при значительной локализации операций записи вне зависимости от кэша. <br />
<i>Read / Write Flash Cache.</i> В случае с флэш кэшем на запись сначала устанавливается максимальный объем кэша, а уровень хранения на SSD появляется лишь при недостаточности размера кэша для обслуживания всей локализованной нагрузки.<br />
Расчет производительности SSD и кэша производится каждый раз исходя из рекомендаций производителя, но всегда для наихудшего варианта.<br />
<div class="blogger-post-footer"><br/>--
<br/><a href="http://blog.vadmin.ru">http://blog.vadmin.ru</a> - Записки виртуального админа</div>Anton Zhbankovhttp://www.blogger.com/profile/00989828695484228304noreply@blogger.com8tag:blogger.com,1999:blog-5320167098569797652.post-55852925201714649262016-06-22T13:19:00.000+03:002016-06-22T13:19:08.903+03:00Дизайн VDC. Расчет ресурсов и выбор архитектуры<b>Разделение на пулы ресурсов</b><br />
<br />
После сбора всей первичной вводной информации первым шагом является группировка наборов данных и ИС в пулы, исходя из моделей угроз и требований регуляторов. Определяется вид разделения различных пулов – программно на уровне системного ПО или физически.<br />
Примеры:<br />
- Контур, обрабатывающий персональные данные, полностью физически отделен от остальных систем;<br />
- Резервные копии хранятся на отдельной СХД.<br />
<br />
При этом пулы могут быть с неполной независимостью, например, определяется два пула вычислительных ресурсов (процессорная мощность + оперативная память), которые используют единый пул хранения данных и единый пул ресурсов передачи данных.<br />
<br />
<b>Процессорная мощность</b><br />
<br />
Абстрактные потребности в процессорной мощность виртуализованного ЦОД измеряется в количестве виртуальных процессоров (vCPU) и коэффициенте их консолидации на физических процессорах (pCPU). В данном конкретном случае 1 pCPU = 1 физическое ядро процессора (без учета Hyper-Threading). Количество vCPU суммируется по всем определенным пулам ресурсов (каждый из которых может иметь свой коэффициент консолидации).<br />
Коэффициент консолидации для нагруженных систем получают эмпирическим путем, исходя из уже существующей инфраструктуры, либо при пилотной установке и нагрузочном тестировании. Для ненагруженных систем применяются «best practice». В частности, VMware называет средним коэффициентом 8:1.<br />
<br />
<b>Оперативная память</b><br />
<br />
Общая потребность в оперативной памяти получается путем простого суммирования. Использование переподписки по оперативной памяти не рекомендуется.<br />
<br />
<b>Ресурсы хранения</b><br />
<br />
Требования по ресурсам хранения получаются путем простого суммирования всех пулов по объему и производительности.<br />
Требования по производительности выражаются в IOPS в сочетании со средним соотношением чтение/запись и при необходимости максимальной задержкой отклика.<br />
Отдельно должны быть указаны требования по обеспечению качества обслуживания (QoS) для конкретных пулов или систем.<br />
<br />
<b>Ресурсы сети передачи данных</b><br />
<br />
Требования по сети передачи данных получаются путем простого суммирования всех пулов пропускной способности.<br />
Отдельно должны быть указаны требования по обеспечению качества обслуживания (QoS) и задержек (RTT) для конкретных пулов или систем. <br />
В рамках требований к ресурсам сети передачи данных так же указываются требования по изоляции и/или шифрованию сетевого трафика и предпочтительным механизмам (802.1q, IPSec и т.д.)<br />
<br />
<b>Выбор архитектуры</b><br />
<br />
В рамках данного руководства не рассматривается иной выбор, кроме архитектуры x86 и 100% виртуализации серверов. Поэтому выбор архитектуры вычислительной подсистемы сводится к выбору платформы серверной виртуализации, форм-фактора серверов и общих требований по конфигурации серверов.<br />
<br />
Ключевым моментом выбора является определенность в использовании классического подхода с разделением функций обработки, хранения и передачи данных или конвергентного.<br />
<br />
<i>Классическая архитектура</i> подразумевает использование интеллектуальных внешних подсистем хранения и передачи данных, в то время как серверы привносят в общий пул физических ресурсов только процессорную мощность и оперативную память. В предельном случае серверы становятся полностью анонимными, не имеющими не только собственных дисков, но даже системного идентификатора. В этом случае используется загрузка ОС или гипервизора с встроенных флэш носителей либо с внешней системы хранения данных (boot from SAN).<br />
В рамках классической архитектуры выбор между лезвиями (blade) и стоечными (rack) осуществляется прежде всего из следующих принципов:<br />
- Экономическая эффективность (в среднем стоечные серверы дешевле);<br />
- Вычислительная плотность (у лезвий выше);<br />
- Энергопотребление и тепловыделение (у лезвий выше удельное на юнит);<br />
- Масштабируемость и управляемость (лезвия в целом требует меньше усилий при больших инсталляциях);<br />
- Использование карт расширения (для лезвий очень ограниченный выбор).<br />
<i><br />
Конвергентная архитектура</i> (также известная как <i>гиперконвергентная</i>) предполагает совмещение функций обработки и хранения данных, что ведет к использованию локальных дисков серверов и как следствие отказу от форм-фактора классических лезвий. Для конвергентных систем используются либо стоечные серверы, либо кластерные системы, совмещающие в едином корпусе несколько серверов-лезвий и локальные диски.<br />
<div class="blogger-post-footer"><br/>--
<br/><a href="http://blog.vadmin.ru">http://blog.vadmin.ru</a> - Записки виртуального админа</div>Anton Zhbankovhttp://www.blogger.com/profile/00989828695484228304noreply@blogger.com0tag:blogger.com,1999:blog-5320167098569797652.post-54674861644993700302016-06-22T11:55:00.001+03:002016-06-22T11:55:36.151+03:00Дизайн VDC. Конфигурация серверов и кластеров виртуализации<div dir="ltr" style="text-align: left;" trbidi="on">
<b>CPU / Memory </b><br />
<br />
Для корректного расчета конфигурации нужно понимать тип нагрузки для среды или каждого из независимых кластеров.<br />
<i>CPU bound</i> – среда, ограниченная по производительности процессорной мощностью. Добавление оперативной памяти ничего не изменит с точки зрения производительности (количества ВМ на сервер).<br />
<i>Memory bound</i> – среда, ограниченная оперативной памятью. Большее количество оперативной памяти на сервере позволяет запустить большее количество ВМ на сервер.<br />
GB / MHz (GB / pCPU) – среднее соотношение потребления данной конкретной нагрузкой оперативной памяти и процессорной мощности. Может использоваться для расчетов необходимого объема памяти при заданной производительности и наоборот. <br />
<br />
<b>Расчет конфигурации сервера</b><br />
<br />
Для начала необходимо определить все виды нагрузки и принять решение о совмещении или разделении различных вычислительных пулов по различным кластерам.<br />
Далее для каждого из определенных кластеров определяется соотношение GB / MHz при известной заранее нагрузке. Если нагрузка не известна заранее, но есть примерное понимание уровня загрузки процессорной мощности, можно использовать стандартные коэффициенты vCPU:pCPU для перевода требований пулов в физические. <br />
<br />
Для каждого кластера сумму требований пулов vCPU делим на коэффициент:<br />
vCPUсумм / vCPU:pCPU = pCPUсумм – требуемое количество физ. ядер<br />
pCPUсумм / 1.25 = pCPUht – количество ядер с поправкой на Hyper-Threading<br />
Предположим, что необходимо произвести расчет кластера на 190 ядер / 3.5ТБ ОЗУ. При этом принимаем целевую 50% загрузку процессорной мощности и 75% по оперативной памяти.<br />
<br />
<table border="1"><tbody>
<tr> <td><br />
<b>pCPU</b></td> <td><br />
190</td> <td><br />
<b>CPU util</b></td> <td><br />
50%</td> <td></td> </tr>
<tr> <td><br />
<b>Mem</b></td> <td><br />
3500</td> <td><br />
<b>Mem util</b></td> <td><br />
75%</td> <td></td> </tr>
<tr> <td><br />
<b>Socket</b></td> <td><br />
<b>Core</b></td> <td><br />
<b>Srv / CPU</b></td> <td><br />
<b>Srv Mem</b></td> <td><br />
<b>Srv / Mem</b></td> </tr>
<tr> <td><br />
2</td> <td><br />
6</td> <td><br />
25,3</td> <td><br />
128</td> <td><br />
36,5</td> </tr>
<tr> <td><br />
2</td> <td><br />
8</td> <td><br />
19,0</td> <td><br />
192</td> <td><br />
24,3</td> </tr>
<tr> <td><br />
2</td> <td><br />
10</td> <td><br />
15,2</td> <td><br />
256</td> <td><br />
18,2</td> </tr>
<tr> <td><br />
2</td> <td><br />
14</td> <td><br />
10,9</td> <td><br />
384</td> <td><br />
12,2</td> </tr>
<tr> <td><br />
2</td> <td><br />
18</td> <td><br />
8,4</td> <td><br />
512</td> <td><br />
9,1</td> </tr>
</tbody></table>
<br />
В данном случае всегда используем округление до ближайшего целого вверх (=ROUNDUP(A1;0)).<br />
Из таблицы становится очевидно, что сбалансированными под целевые показатели являются несколько конфигураций серверов:<br />
- 26 серверов 2*6c / 192 GB<br />
- 19 серверов 2*10c / 256 GB<br />
- 10 серверов 2*18c / 512 GB <br />
<br />
Выбор из этих конфигураций в дальнейшем необходимо делать исходя из дополнительных факторов, как например тепловой пакет и доступное охлаждение, уже используемые серверы, или стоимость.<br />
<br />
<b>Особенности выбора конфигурации сервера</b><br />
<br />
Широкие ВМ. При необходимости размещения широких ВМ (сравнимых с 1 узлом NUMA и более) рекомендуется по возможности выбирать сервер с конфигурацией, позволяющей таким ВМ остаться в пределах NUMA узла. При большом количестве широких ВМ возникает опасность фрагментирования ресурсов кластера, и в этом случае выбираются серверы, позволяющие разместить широкие ВМ максимально плотно.<br />
<br />
<b>Размер домена единичного отказа.</b> <br />
<br />
Выбор размера сервера также осуществляется из принципа минимизации домена единичного отказа. Например, при выборе между:<br />
- 3 x 4*10c / 512 GB<br />
- 6 x 2*10c / 256 GB<br />
При прочих равных необходимо выбирать второй вариант, поскольку при выходе одного сервера из строя (или обслуживании) теряется не 33% ресурсов кластера, а 17%. Точно так же вдвое снижается количество ВМ и ИС, на которых отразилась авария.</div>
<div class="blogger-post-footer"><br/>--
<br/><a href="http://blog.vadmin.ru">http://blog.vadmin.ru</a> - Записки виртуального админа</div>Anton Zhbankovhttp://www.blogger.com/profile/00989828695484228304noreply@blogger.com0tag:blogger.com,1999:blog-5320167098569797652.post-26251694696403811092016-06-21T15:06:00.000+03:002016-06-21T15:06:43.608+03:00Cloud Trust.<div dir="ltr" style="text-align: left;" trbidi="on">
When we talk of information security, including cloud security, most of the talk is about confidentiality. Well, as from my experience almost no one talks about 2 other parts of the triad – integrity and availability. But these attributes become crucial in cloud.<br />
<br />
Why are we doing cloud in the first place? To cut expenses, both capital and operational – dollar saved is dollar earned. Guess what cloud provider does? The very same thing, cutting expenses as much as they could. And there is no easy answer to the question: make cloud more secure or save some money.<br />
<br />
Let’s take an easy example, how can cloud provider protect your data confidentiality? For data at rest it’s pretty obvious answer – encryption. For data-in-flight there is no answer at all, encryption cannot protect from privileged insider – all the keys and hashes can be sniffed during live migration or through snapshotting. There are no measures to protect your data with 100% assurance, but all have costs. With the BIG providers you can be sure there are some internal security policies to prevent insider access and those who have access are not random people from the street. As cloud computing market grows we see a lot of smaller providers with nice prices for the service, but… So there are some basic questions for you provider you would really like to have an answer before moving your data:<br />
1) Who has an access to hardware?<br />
2) How much access do admins have?<br />
3) Who is watching them?<br />
4) Is there internal backup?<br />
5) Who has an access to backups?<br />
6) What really happens with our data when we close account?<br />
<br />
I personally know a small company providing a very good service for accounting and supply management from the cloud. But they haven’t deleted any data in their entire history – everything is still in their databases. You closed your account 2 years ago – doesn’t matter. Data is still here.<br />
<br />
Important part of the cloud is multitenancy – all the tenants use the very same shared hardware infrastructure, it saves money. But also it imposes new risks we never saw before cloud. Questions for provider:<br />
1) How tenants are isolated?<br />
2) Who grants tenant admin rights?<br />
3) Who is watching them (both admins and tenant admins)?<br />
4) How tenant admin is authenticated?<br />
5) What really happens with our data when we close account?<br />
<br />
The last question is exactly the same, but with different aspect – who ensures our data is not accessible one way or another by other tenant taking over hardware resources we used to have?<br />
And this is an easy part, because we’re moving to integrity and availability which are most of the time considered as operations team responsibility with almost no attention from security team.<br />
<br />
You’ve rented some VMs from the provider. How do you know where exactly data is stored and how reliable storage system is? Is it high end EMC Symmetrix system or DIY in garage 90TB storage like this one?<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi3jP4uTsmjsByCAIhYUBaMITyDLvUwNDH50eb0zVt86Ea5G1wSVst_33FglLvgMTiYBfExbAeuZrvexNo4aql4vZSw2_taJC8HpAgiJ9SFcIN6zKzmxyKhWi4tli-pkD4rJVwoNAY3RiQ/s1600/symmetrix+diy.png" imageanchor="1"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi3jP4uTsmjsByCAIhYUBaMITyDLvUwNDH50eb0zVt86Ea5G1wSVst_33FglLvgMTiYBfExbAeuZrvexNo4aql4vZSw2_taJC8HpAgiJ9SFcIN6zKzmxyKhWi4tli-pkD4rJVwoNAY3RiQ/s320/symmetrix+diy.png" width="240" /></a><br />
<br />
Most providers do not use classic corporate storage systems with known performance and proven reliability. DIY storage is way to cut really big piece of investment, but… here are 2 examples from Russian provider space:<br />
1) “Selectel” have lost customers data several times due to problems with linux mdraid service.<br />
2) “Cloudmouse” irreversibly lost 22 000 VMs due to problems with ceph service. <br />
<br />
And personally I wonder – have these guys ever heard of backup? BTW have your provider heard?<br />
Okay, I’ve scared you a little of cloud, so now let’s compare it to good old home-made IT. We’re building it for years and we know everything and control everything. Right?<br />
98% of ITs I’ve seen – wrong. There are a lot of reasons for that, like:<br />
1) There is just not enough qualified personnel <br />
2) IT manager and whole IT department trying to maintain their personal importance instead of pursuing company needs<br />
3) There were mistakes made before and company still paying for that<br />
4) Some decisions were purely political instead of technical<br />
5) … and this list can be 100 pages long.<br />
<br />
So what should we do about it and what’s the magic word?<br />
<br />
It is Trust. And particularly Cloud Trust. I’ve tried to extract the meaning of this word:<br />
- Trust is situation when you are sure in other party words/deeds<br />
<br />
Outside IT you gain trust, it is a process. And you gain it with time when you prove yourself trustworthy. I believe everyone agree that you should trust your cloud provider if you move your data and intellectual property to their premises. Experience is the thing that came right after it was needed. <br />
What we do with our relations with new people and establishing if we can trust them is calling for trusted 3rd party. You cannot be sure if a man or woman right across the table is a real doctor, so you ask for diploma from university you trust.<br />
Unfortunately in cloud provider space there is no trusted authority to certify one or another provider. There are several organizations to help us though, like global Cloud Security Alliance with ready to use questionnaires. You just take it and ask your provider to answer these questions for you.<br />
<br />
From other side what I see – most of companies exaggerate importance of their data, because they don’t really have a clue. Netherlands police for example took a deep look into data they have. Guess what they have found – 95% of everything they have is NOT confidential. How much commercial company data is really confidential you think? <br />
<br />
What should you do before considering cloud services.<br />
1) Clean up a mess in your internal IT. Cloud is about automation, and when you automate the mess – you get automated mess.<br />
2) Classify your data. There is no need in 100 different types and security classes, 3 to 5 would be just fine.<br />
3) Start with new non-confidential data. <br />
4) Start with new test zone in the cloud.<br />
5) Start with secondary and support processes.<br />
6) Deploy seasonal and peak loads in the cloud.<br />
7) Create and test backup policy with offsite data storage, so if cloud goes down you have at least backups.<br />
<br />
<b>DO NOT</b><br />
<br />
1) Replicate your services as they are.<br />
2)Move everything at once, especially business critical applications.</div>
<div class="blogger-post-footer"><br/>--
<br/><a href="http://blog.vadmin.ru">http://blog.vadmin.ru</a> - Записки виртуального админа</div>Anton Zhbankovhttp://www.blogger.com/profile/00989828695484228304noreply@blogger.com0tag:blogger.com,1999:blog-5320167098569797652.post-83075785252042179962016-06-21T13:18:00.000+03:002016-06-22T11:55:56.251+03:00Дизайн VDC. С чего надо начинать<div dir="ltr" style="text-align: left;" trbidi="on">
<b>Введение</b><br />
<br />
Информационная система с точки зрения пользователя хорошо определяется в ГОСТ РВ 51987 - «автоматизированная система, результатом функционирования которой является представление выходной информации для последующего использования». Если рассматривать внутреннюю структуру, то по сути любая ИС является системой реализованных в коде взаимосвязанных алгоритмов. В широком понимании тезиса Тьюринга-Черча алгоритм (а сл-но ИС) осуществляет трансформацию множества входных данных в множество выходных данных. <br />
Можно даже сказать, что в трансформации входных данных и есть смысл существования информационной системы. Соответственно ценность ИС и всего комплекса ИС определяется через ценность входных и выходных данных.<br />
Исходя из этого проектирование должно начинаться и брать за основу данные, подстраивая архитектуру и методы под структуру и значимость данных.<br />
<br />
<b>Хранимые данные</b><br />
Ключевым этапом подготовки к проектированию является получение характеристик всех наборов данных, планируемых к обработке и хранению. Эти характеристики включают в себя:<br />
- Объем данных;<br />
- Информация о жизненном цикле данных (прирост новых данных, срок жизни, обработка устаревших данных);<br />
- Классификация данных с т.з. влияния на основной бизнес компании (то триаде конфиденциальность, целостность, доступность) вместе с финансовыми показателями (напр. стоимость утери данных за последний час);<br />
- География обработки данных (физическое расположение систем обработки);<br />
- Требования регуляторов по каждому классу данных (напр. ФЗ-152, PCI DSS).<br />
<br />
<b>Информационные системы</b><br />
<br />
Данные не только хранятся, но и обрабатываются (трансформируются) информационными системами. Следующим шагом после получения характеристик данных является максимально полная инвентаризация информационных систем, их архитектурных особенностей, взаимозависимостей и требований к инфраструктуре в условных единицах к четырем видам ресурсов:<br />
- Процессорная вычислительная мощностьl;<br />
- Объем оперативной памяти;<br />
- Требования к объему и производительности системы хранения данных;<br />
- Требования к сети передачи данных (внешние каналы, каналы между компонентами ИС).<br />
Требования при этом должны быть на каждый сервис/микросервис в составе ИС.<br />
Отдельно необходимо отметить обязательное для корректного проектирования наличие данных по влиянию ИС на основной бизнес компании в виде стоимости простоя ИС (рублей в час).<br />
<br />
<b>Модель угроз</b><br />
<br />
В обязательном порядке должна быть в наличии формальная модель угроз, от которых планируется защищать данные / сервисы. При этом модель угроз включает в себя не только аспекты конфиденциальности, но и целостности и доступности. Т.е. например:<br />
- Выход из строя физического сервера;<br />
- Выход из строя коммутатора top-of-the-rack;<br />
- Разрыв оптического канала связи между ЦОД;<br />
- Выход из строя оперативной СХД целиком.<br />
В некоторых случаях модели угроз пишутся не только для инфраструктурных компонентов, но и для конкретных ИС или их компонентов, как например отказ СУБД с логическим разрушением структуры данных. <br />
Все решения в рамках проекта по защите против не описанной угрозы являются излишними.<br />
<br />
<b>Требования регуляторов</b><br />
<br />
Если обрабатываемые данные попадают под действие специальных правил, устанавливаемых регуляторами, в обязательном порядке необходима информация о наборах данных и правилах обработки/хранения.<br />
<br />
<b>Целевые показатели RPO / RTO</b><br />
<br />
Проектирование любого вида защиты требует наличия показателей целевой потери данных и целевого времени восстановления сервиса для каждой из описанных угроз.<br />
При этом в идеале RPO и RTO должны иметь ассоциированные стоимости потери данных и простоя в единицу времени.</div>
<div class="blogger-post-footer"><br/>--
<br/><a href="http://blog.vadmin.ru">http://blog.vadmin.ru</a> - Записки виртуального админа</div>Anton Zhbankovhttp://www.blogger.com/profile/00989828695484228304noreply@blogger.com0tag:blogger.com,1999:blog-5320167098569797652.post-17084013026469938042016-03-25T17:12:00.000+03:002016-03-25T17:12:19.544+03:00Безопасность - это не только конфиденциальность. РусКрипто 2016.<div dir="ltr" style="text-align: left;" trbidi="on"><iframe src="//www.slideshare.net/slideshow/embed_code/key/Cm2NfYPsXpJt4" width="595" height="485" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe> <div style="margin-bottom:5px"><strong> <a href="//www.slideshare.net/antonvirtual/ss-60026933" title="Безопасность - это не только конфиденциальность" target="_blank">Безопасность - это не только конфиденциальность</a> </strong> from <strong><a target="_blank" href="//www.slideshare.net/antonvirtual">Anton Zhbankov</a></strong> </div></div><div class="blogger-post-footer"><br/>--
<br/><a href="http://blog.vadmin.ru">http://blog.vadmin.ru</a> - Записки виртуального админа</div>Anton Zhbankovhttp://www.blogger.com/profile/00989828695484228304noreply@blogger.com0tag:blogger.com,1999:blog-5320167098569797652.post-6095747143684798382015-11-30T14:31:00.004+03:002015-11-30T15:12:04.876+03:00VMware User Group 2015-2. Программа<div dir="ltr" style="text-align: left;" trbidi="on">Все меньше времени остается до 8го декабря.<br />
Место проведения Best Western Vega Hotel & Convention Center, Москва.<br />
Начало регистрации 10-00, начало мероприятия 10-30<br />
<br />
<ul style="text-align: left;"><li>"Docker в виртуальной среде VMware”, Андрей Коновалов, Инфосистемы Джет, vExpert</li>
<li>"Правила хорошего тона при дизайне виртуализованного датацентра”, Антон Жбанков, vExpert, Cloud Architect.</li>
<li>"Работа с инженерной графикой в VMware Horizon View”, Алексей Худяков, Гипрогазочистка, зам. генерального директора</li>
<li>"Secured Horizon View Architecture" Edward Haletky, vExpert, Cloud Security Architect</li>
<li>"VMware VSAN как она есть." Николай Куликов, VMware</li>
<li>vПроекты 2015 года. Накопленный опыт и практические советы. Владислав Кирилин, VMware PSO, Consultant.</li>
<li>“Встроенные средства обеспечения безопасности VMware vSphere. Сухо и комфортно.” Антон Жбанков, vExpert, Cloud Architect.</li>
<li>"Плюсы и минусы архитектуры Horizon Cloud Pod." Николай Куликов, VMware</li>
<li>"Наши самые интересные проекты. Байки из склепа" круглый стол</li>
</ul><br />
<br />
<a href="http://blog.vadmin.ru/2015/10/vmware-user-group-russia-winter-2015.html">Регистрация</a> обязательна.<br />
<br />
</div><div class="blogger-post-footer"><br/>--
<br/><a href="http://blog.vadmin.ru">http://blog.vadmin.ru</a> - Записки виртуального админа</div>Anton Zhbankovhttp://www.blogger.com/profile/00989828695484228304noreply@blogger.com0tag:blogger.com,1999:blog-5320167098569797652.post-47649519946589430772015-11-18T11:23:00.000+03:002015-11-18T11:26:49.034+03:00VMware Online Technology Forum<div dir="ltr" style="text-align: left;" trbidi="on">Не пропустите технологический форум <a href="https://event.on24.com/eventRegistration/EventLobbyServlet?target=registration.jsp&eventid=1071459&sessionid=1&key=3C36E3C980FA12C05D7868517C11FEE8&partnerref=PEMEA-NetNew&sourcepage=register">VMware Online Technology Forum</a> 25 ноября 12:00 – 16:30 по московскому времени. Это бесплатное online мероприятие, где мы расскажем о новых разработках для единого гибридного облака и других технологических новинках, которые при помощи программно-определяемых технологий позволяют вам ускорить внедрение новых приложений и услуг. Мы расскажем обо всех последних решениях и технологиях, включая продукты NSX, vCloud Air и EVO:RAIL. Кроме того, наши эксперты всегда готовы ответить на ваши вопросы в режиме онлайн.<br />
Зарегистрируйтесь сейчас и получите доступ к общению с партнерами в рамках технологических сессий и практических лабораторных занятий. Технические эксперты VMware, среди которых Джо Багли (VP & CTO, EMEA), Дункан Эппинг (главный технолог), Майк Лаверик (архитектор по интеграции продуктов), Дэвид Хилл (старший архитектор по техническому маркетингу vCloud Air) и Питер Бьорк (главный системный инженер), будут рады ответить на ваши вопросы.<br />
<br />
<br />
Технологические сессии будут посвящены следующим темам:<br />
<br />
Гибридное облако: продвинутые сетевые услуги vCloud Air<br />
<br />
Мобильность бизнеса: VMware Horizon – улучшение работы Citrix<br />
<br />
Программно-определяемый ЦОД: Инфраструктура: управление центром обработки и хранения данных с помощью vRealize Operations Insight 6.1<br />
<br />
Программно-определяемый ЦОД: Новые услуги: облачные приложения и контейнеры<br />
<br />
Программно-конфигурируемые сети: использование NSX для расширения сети с участием множественных ЦОД<br />
<br />
<a href="https://event.on24.com/eventRegistration/EventLobbyServlet?target=registration.jsp&eventid=1071459&sessionid=1&key=3C36E3C980FA12C05D7868517C11FEE8&partnerref=PEMEA-NetNew&sourcepage=register">Зарегистрируйтесь</a> сейчас чтобы услышать: <br />
• Аудиодискуссии с экспертами VMware в режиме реального времени с возможностью задавать вопросы и получать ответы<br />
• Наиболее интересные моменты лабораторных с участием создавших их экспертов VMworld<br />
• Технологические сессии, которые вы выберете сами<br />
<br />
Присоединяйтесь к нам в среду, 25 ноября!<br />
<br />
<br />
</div><div class="blogger-post-footer"><br/>--
<br/><a href="http://blog.vadmin.ru">http://blog.vadmin.ru</a> - Записки виртуального админа</div>Anton Zhbankovhttp://www.blogger.com/profile/00989828695484228304noreply@blogger.com0tag:blogger.com,1999:blog-5320167098569797652.post-8300393870640787442015-11-15T02:38:00.000+03:002015-11-15T02:38:14.663+03:00Virtual DataCenter Design. Host Sizing. 1<div dir="ltr" style="text-align: left;" trbidi="on">
<b>Hyper-Threading</b><br />
<br />
A lot of times I see two contradictory approaches on how to include HyperThreading to sizing. You can just ignore HT at all, and calculate CPU power based on “real” cores, or you can double CPU power because you see twice as much logical CPUs. Unfortunately they’re both wrong. In general you can safely assume HT as +25% CPU, but with some ifs. The main IF is that HT makes most of the efficiency on workloads with a lots of small VMs. Let’s assume we have a dual-way host with 12-core CPUs. That means 24 “real” cores, or 30 “effective” cores. But 24 vCPUs would still be the widest VM you should place on that host.<br />
<br />
<b>1 or 2 or 4</b><br />
<br />
Should we choose 2-way or 4-way servers for virtualization? Pretty common problem. So how to solve it?<br />
<br />
Target workload is the answer 100% of the cases, and fault domain size. Fault domain in this case is one host. Let’s assume we have a target workload of 200 VMs that can be handled by 10 dual-way hosts with 256GB of RAM each. It’s not a rocket science to deduct that 5 4-way hosts with 512 GB of RAM can handle this workload as well. But! In case of HA event we’ll have double number of VMs affected with services, double number of VMs to restart, increased load on SAN. We have 20% of resources gone from cluster instead of 10% for dual-way servers. And that’ not all, for the planned maintenance we have to evacuate twice as much VMs which leads us to 2-2,5 times more evacuation time.<br />
<br />
Latest improvements in CPU design bring us unprecedented number of cores per single socket, making 2-way vs 4-way quarrel even more complicated. Why the hell not 1-way servers with 16-18 cores CPU?<br />
<br />
Conclusion. 4-way servers should be used in such cases as:<br />
- Need to use Xeon E7 CPUs instead of E5. But still we can use 4 way servers with 2 sockets filled.<br />
- Need for ultra-wide VMs size of full 2-way server or more, without possibility of application level clustering to split the load.<br />
<br />
<b>CPU choice</b><br />
<b><br /></b>
How to choose CPU in the family – that’s the question. You can try to stick your finger in the sky, use the coin or even a prophecy. But still most of the choices are made without real thinking. Let’s take a view on some basic aspects.<br />
- NUMA. All the current x86 CPUs have the NUMA architecture. So each CPU has it’s own memory instead of globally shared. You have to access another CPU’s memory through the owner which is slower. But that’s not actually the problem, it’s just an issue to consider. Real problem is that you cannot install only half of maximum memory if you don’t install second CPU on 2-way server.<br />
- CPU price, and price per core.<br />
- Software licenses cost.<br />
<br />
Let’s assume we chose Intel R1304WT2GS as basic platform for virtualization. So now we should to decide number of CPU to achieve maximum performance / cost efficiency. We are planning to install vSphere Standard ($1940), Windows 2012R2 Datacenter for VMs ($6155 / 2 CPUs) and Veeam Backup Standard ($1116). <br />
Hardware costs $7970 for 1 socket configuration (E5-2670v3 12c + 192 GB), and we need licenses for 1 socket, which would be another $6133 resulting in approx. $14100 total.<br />
2 socket configuration with the very same performance characteristics would cost $6890 (dual E5-2620v3 6с + 192 GB), but software costs double and result is $19160. So with the very same performance characteristics 1-way server is cheaper and a little bit faster due to just 1 NUMA node. Disclaimer – this is not 100% correct calculation, but a mere example of way to calculate.<br />
<br />
So why do we need 2-way or even 4-way systems?<br />
- 2 way servers have twice as much maximum memory.<br />
- Single CPU is not enough for really highly loaded applications.<br />
- As a general rule the more cores CPU have – the less is frequency. For an application with core-based licensing such as Oracle DB that can be an issue. For example, 2*E5-2637 v3 (4с, 3.50 GHz) and 1*E5-2667 v3 (8с, 3.20 GHz) have 10% difference in peak performance (28GHz vs 25,6GHz) while core-based licenses would remain the same.<br />
<br />
General recommendations:<br />
- Multi-core CPUs are well suited for loads with a lot of lightly to medium loaded VMs. More cores are better.<br />
- The wider VMs are used – the better they perform.<br />
- If you have only a few VMs with applications known for their love for MHz instead of good parallel procession – stick to higher frequency CPUs with less cores.<br />
- Always start you design with single CPU servers. Add second CPU only after a minimum of 5 hosts reached (except of vSphere Essentials) or when you really need more memory that single CPU can support. Or leave second socket for a future upgrade.</div>
<div class="blogger-post-footer"><br/>--
<br/><a href="http://blog.vadmin.ru">http://blog.vadmin.ru</a> - Записки виртуального админа</div>Anton Zhbankovhttp://www.blogger.com/profile/00989828695484228304noreply@blogger.com0tag:blogger.com,1999:blog-5320167098569797652.post-82182213116715856192015-11-13T15:31:00.000+03:002015-11-13T16:06:41.876+03:00Дизайн VDC. Сайзинг хостов. 1<div dir="ltr" style="text-align: left;" trbidi="on">
<b>Hyper Threading</b><br />
<b><br /></b>
Часто встречаются два противоположных и неверных утверждения – HT не надо учитывать, и учитывать надо как полные ядра, т.е. умножать на два.<br />
HT при сайзинге следует учитывать как +25% процессорной мощности. Хост с 2 процессорами по 12 ядер и HyperThreading имеет 24 ядра или 48 потоков, что с указанным коэффициентом дает мощность, эквивалентную 30 ядрам.<br />
Следует отдельно отметить, что максимальный размер ВМ в этом случае должен быть не более 24 vCPU. Hyper-Threading дает максимальный эффект на большом количестве ВМ с малым количеством vCPU.<br />
<br />
<b>1 или 2 или 4</b><br />
<b><br /></b>
Выбор между 2х или 4х процессорными серверами под виртуализацию следует делать исходя из типа нагрузки, планируемой для данного конкретного кластера. Ключевой показатель – это размер домена отказа. Т.е. насколько виртуальная ферма и продуктивная нагрузка пострадает от отказа единичного сервера. Предположим, под 200 продуктивных ВМ нам требуется 10 2х-процессорных серверов с 256 ГБ памяти. Очевидно, что их можно заменить 5ю 4х-процессорными серверами с 512 ГБ памяти без потери производительности. Однако это означает удвоенное количество ВМ на сервер, и соотв. двойной объем памяти ВМ в нагрузке. При выходе одного хоста из строя и срабатывании HA мы имеем разницу в два раза по количеству ВМ и продуктивных сервисов в рестарте, увеличенную нагрузку на СХД при рестарте ВМ. А также выход двойного объема ресурсов из кластера – 20% (4х) против 10% (2х). При запланированном простое хоста (под регламентные работы) двойное количество ВМ требуют миграции, что в 2-2.5 раза увеличивает время самой миграции. <br />
<br />
С учетом роста количества ядер в процессорах для 2х процессорных серверов, возникает смысл в переходе даже на 1-процессорные серверы.<br />
<br />
Итого. 4х процессорные серверы под виртуализацию рекомендуются в следующих случаях:<br />
- необходимость использования иного семейства процессоров (Xeon E7, а не E5) под продуктивную нагрузку. В этом случае 4х процессорный сервер может быть с 2мя установленными процессорами.<br />
- необходимость в размещении сверхшироких ВМ, шириной в полный двухпроцессорный физический сервер или более, при невозможности или экономической неэффективности кластеризации приложения с разделением нагрузки на ВМ меньшей ширины.<br />
<br />
<b>Выбор процессора </b><br />
<b><br /></b>
Выбор процессора внутри семейства затрагивает сразу несколько параметров, которые необходимо рассмотреть.<br />
- NUMA. Все современные x86 процессоры имеют архитектуру NUMA. Т.е. у каждого процессора в сервере есть своя память, и обращение к чужой памяти напрямую невозможно. Иными словами, если в 2х процессорном сервере установлен 1 процессор, то памяти можно установить только половину от максимально возможной.<br />
- Стоимость самого процессора и стоимость в расчете на ядро.<br />
- Стоимость лицензий на системное и прикладное ПО и модель лицензирования.<br />
<br />
Предположим, что в качестве платформы выбран сервер Intel R1304WT2GS, и теперь стоит вопрос сколько и каких процессоров в него установить для максимальной экономической эффективности. В качестве ПО предполагается vSphere Standard ($1940), Windows 2012 R2 Datacenter ($6155 / 2 CPU), Veeam Backup Standard ($1116).<br />
Итак, для конфигурации 1xE5-2670v3 (12c) и 192 GB сервер будет стоить в сборе $7970 и потребует по 1 лицензии ПО (лицензирование по сокетам), что дает $6133 за софт или $14100 за сервер.<br />
При выборе варианта с 2мя процессорами E5-2620v3 (6с) стоимость самого сервера уменьшается до $6890, однако стоимость лицензий удваивается и дает $19160. /* расчет не является 100% корректным и призван лишь проиллюстрировать сам принцип<br />
При равной мощности и объеме памяти двухпроцессорный сервер обладает большей ценой (спасибо лицензиям) и потенциально меньшей производительностью за счет 2х узлов NUMA. <br />
<br />
Так зачем же нам нужны двухпроцессорные и, тем более, четырехпроцессорные серверы?<br />
- В двухпроцессорном сервере вдвое больше максимальный объем памяти.<br />
- Одного, даже топового, процессора может не хватать по вычислительной мощности. <br />
- Многоядерные процессоры не всегда имеют высокую тактовую частоту, а стоимость лицензий на системное ПО значительно ниже стоимости прикладного ПО, лицензируемого по ядрам. Например 2*E5-2637 v3 (4с, 3.50 GHz) и 1*E5-2667 v3 (8с, 3.20 GHz) имеют 10% разницу в пиковой производительности (28GHz vs 25,6GHz), что может стать решающим фактором для выбора процессоров для нагруженной Oracle DB.<br />
<br />
Общие рекомендации:<br />
- Многоядерные процессоры хорошо подходят для большого количества ВМ малой или средней загрузки. <br />
- Чем более широкие ВМ используются – тем лучше они работают на многоядерных процессорах.<br />
- Если машин немного и прикладное ПО плохо работает с параллельными потоками, предпочитая частоту, то выбор должен осуществляться в пользу процессоров с большей частотой в ущерб количеству ядер.<br />
- Надо всегда начинать с варианта с одним процессором, и добавлять второй только при нехватке памяти, или оставлять второй процессор как опцию под будущий апгрейд виртуальной фермы.</div>
<div class="blogger-post-footer"><br/>--
<br/><a href="http://blog.vadmin.ru">http://blog.vadmin.ru</a> - Записки виртуального админа</div>Anton Zhbankovhttp://www.blogger.com/profile/00989828695484228304noreply@blogger.com0tag:blogger.com,1999:blog-5320167098569797652.post-81111531363557078492015-10-27T16:37:00.001+03:002015-10-27T16:37:57.322+03:00VMware User Group Russia - Winter 2015 Регистрация<div dir="ltr" style="text-align: left;" trbidi="on">Друзья, рад сообщить о новой встрече русскоязычного сообщества VMware в Москве 8го декабря.<br />
Программа мероприятия в процессе подготовки. И в этот раз у нас будет еще больше отличных докладов без маркетинга, чем обычно. Желающие рассказать о своем опыте и граблях, или напротив, о счастье и невыносимой легкости с VMware - у вас есть все шансы! <br />
<br />
<iframe src="https://docs.google.com/forms/d/1ljH6t0SDtdTduTevbotLMAwNWQJSs_4rfjJirtKW1Q0/viewform?embedded=true" width="760" height="860" frameborder="0" marginheight="0" marginwidth="0">Loading...</iframe><br />
<br />
Включайтесь в нашу онлайн-группу в Facebook: <a href="https://www.facebook.com/groups/vmug.ru/">VMUG.RU</a><br />
</div><div class="blogger-post-footer"><br/>--
<br/><a href="http://blog.vadmin.ru">http://blog.vadmin.ru</a> - Записки виртуального админа</div>Anton Zhbankovhttp://www.blogger.com/profile/00989828695484228304noreply@blogger.com0