Записки о виртуализации и о жизни
С виртуализацией я плотно общаюсь с середины 2007 года. Начинал я общение еще с VMware Virtual Infrastructure 3.5, после которой и появилось модное словцо “vSphere”.
Иногда мне приходится отвечать на вопрос, в чем различие разных версий vSphere. Попробую дать ответ ниже и описать появление функционала в различных версиях…
Если можете поведать еще о каких-то интересных фичах, не вошедших в этот обзор – пишите в комментариях со ссылками – обязательно добавлю…
Сегодня о “худшей практике” одной настройки виртуальной машины.
Некоторое время назад обнаружились серверы с большим уровнем IOPS – в районе 1000-1500 операций. Экспресс-диагностика не дала результата, а так как размер дисков машин был очень небольшим, то они были перемещены на локальные SSD, что сняло остроту проблемы.
Сейчас же обнаружились проблемы с терминальными серверами – довольно сильные лаги при большом количестве подключений. Анализ системы показал довольно классическую проблему – наличие baloon. Наличие “пузыря” в памяти насторожило, так как на хосте свободной памяти было с избытком. Ларчик открылся просто при 3 ГБ ОЗУ виртуальной машины стояла волшебная труодминская настройка memory limit 2 ГБ. К пущей радости, история умалчивает кто был этим тру одмином.
После такого открытия я запустил RVTools и проинспектировал все виртуальные машины на наличие лимитов памяти, ну, и на “пузыри” заодно.
Тут-то и всплыли виртуалки с большими IOPS, так как настройки на них были примерно следующие ОЗУ – 1,5 ГБ, лимит – 256 МБ. На одной из машины при ОЗУ 3 ГБ, лимит был 512 МБ, а размер “пузыря” 2 ГБ.
Для чего понадобилось выставлять лимиты остаётся загадкой. Поснимал все лимиты на память, так как для моей конфигурации данный функционал не имеет смысла.
Примерно 2,5 года назад вышел документ по решению проблем с производительностью в VMware vSphere 4.1.
Так как актуальность документ все еще не потерял, я попробую осуществить его перевод…
В начале документа находится схема траблшутинга
Соответственно, есть две дальнейшие диаграммы: базовая и продвинутая.
Continue reading “Решение проблем с производительностью VMware vSphere – часть 1”
У меня на хосте закладка Hardware Status в vCenter Server стабильно выдавала ошибку “Hardware monitoring service on this host is not responding or not available”, даже после перезагрузки хоста.
Совет в KB не помогал. Вместо этого я подключился напрямую к хосту и в Configuration – Health status нажал Reset Sensors. Минут через 5-10 статусы с Unknown поменялись на Normal, хотя счетчиков примерно в 2 раза меньше, чем в vCenter.
После этого зашел в Hardware Status, и через несколько минут после обновления все счетчики стали отображаться.
Rick Vanover опубликовал данную статью, в которой перечисляет 5 граблей, на которые вам лучше не вставать.
Я люблю гибкость, которую дает мне виртуализация VMware vSphere. Временами это может причинять неудобства. При записи подкаста с Greg Stuart мы пришли к выводу, что практически нет одинаковых виртуальных окружений.
Таким образом мы пришли к вопросу: как виртуальные среды могут так различаться? Что было сделано правильно, а что – нет? Я предлагаю вам свой список настроек, которыми нельзя пренебрегать.
Continue reading “5 вещей, которые не стоит делать с vSphere”
Дошли у меня руки до обновления версии своих хостов до 5.1. Лицензии на vSphere 5 куплены в редакции Enterprise, поэтому пришлось заодно отказываться и от распределенного коммутатора.
Итак, поехали.
Сегодня при обновлении VMware Tools на одной из виртуальных машин, столкнулись со следующей ошибкой:
“Tools is not supported on FreeBSD < 6.3. Detected FreeBSD version 6.2. Execution aborted.”
Данная статья является переводом статьи Duncan Epping об использовании резерва ресурсов по процентам. Этот тип резервирования (или Admission control) является любимым у Duncan’а, и я попытаюсь объяснить почему.
Вы все видели настройку HA-кластера, в которой настраивается тип резервирования ресурсов. Лично я предпочитаю резервирование ресурсов по процентам, хотя есть мнение, что это снижает вероятность перезапуска “больших” ВМ. Эти люди считают, что резервирование по слотам (host failures) дает большую вероятность перезапуска “больших” ВМ. Они все неправы 🙂 Давайте я приведу пример, который покажет ошибочность этого мнения.
При бэкапе виртуальной инфраструктуры с помощью Veeam Backup and Replication 6.5 одна из виртуальных машин перестала бэкапиться с ошибкой “Creating snapshot Error: The method is disabled by ‘MVDI'”.
Гугление результатов не дало, пошел разбираться…
Continue reading “Veeam Backup creating snapshot Error: The method is disabled by ‘MVDI’”
Преамбула: первоначально статья рассматривалась, как памятка по настройке стандартного коммутатора для ESX из консоли, но позже было решено написать более подробную статью.
Достаточно подробное сравнение ESX (“толстый” гипервизор) и ESXi (“тонкий” гипервизор”) версии 4.1 сделано VMware. Стоит также отметить, что в vSphere 5/5.1 остался только ESXi. В рамках этой статьи я затрону два различия:
1) Для управления ESX извне используется подключение к виртуальному интерфейсу Service Console или vswif#. Для настроек из консоли сервера используется команда esxcfg-vswif. Для управления ESXi используется виртуальный интерфейс VMKernel или vmk#. Для настроек из командной строки – esxcfg-vmknic.
2) Для управления из консоли сервера ESXi можно использовать черно-желтый интерфейс DCUI, либо командную строку. Для ESX доступна только командная строка. При использовании распределенного коммутатора совместно с ESXi в DCUI есть пункт меню по восстановлению стандартного коммутатора на сервере ESXi.
После миграции виртуальных сетей на распределенный коммутатор, у вас есть два варианта: мигрировать туда же сети управления, или оставить их на стандартном коммутаторе. Если “лишних” сетевых адаптеров нет, то и выбора, в общем-то, тоже 🙂
Соответственно, иногда могут случаться различные проблемы с доступом к серверу через сеть. Просто поменять адрес или добавить новый виртуальный интерфейс уже не получится, так как вам нужно его добавлять на распределенный коммутатор, а вы не можете туда подключиться. Приходится как раз восстанавливать стандартный коммутатор, что делается элементарно через DCUI у ESXi. А вот как это делать на ESX я сейчас покажу.
Continue reading “Восстановление стандартного коммутатора из консоли ESX 4.1”