Вход|Регистрация

Неразборчивое о виртуальном
Записи с меткой vSphere 5

Note to remember: vCS 5.1 without AD

Четверг, 20 марта 2014, 17:31

При создании прототипа инфраструктуры в лаборатории столкнулись со странной пролемой:
После установки vCS 5.1 (Simple install) всё работает до первого перезапуска виртуальной машины. После ребута ОС сервис VMware VirtualCenter Server не запускается. Остальные службы в состоянии Started.

В логах vCS присутствует: "No connection could be made because the target machine actively refused it".

Причина.
База данных vCS находится в MS SQL Express. По умолчанию Express использует для подключения динамические порты.

Конфигурация подключения SSO-сервера к БД хранится в файле: C:\Program Files\VMware\Infrastructure\SSOServer\webapps\lookupservice\WEB-INF\classes\config.properties


После первой же перезагрузки порт СУБД меняется, что по какой-то причине не отслеживает SSO-сервер в своей конфигурации. При этом, сам сервис vCenter Single Sing On стартует без ошибок!

Решение.

  1. Стопим сервис vCenter Single Sing On.
  2. В консоли Sql Server Configuration Manager-> TCP/IP-> IP ALL-> удалить текущее значение в Dynamic Ports и прописать статический порт 1433. Рестарт сервис MS SQL EXP.
  3. В cmd перейти по адресу C:\Program Files\VMware\Infrastructure\SSOServer\utils (путь по-умолчанию) и выполнить: ssocli configure-riat -a configure-db --database-host <hostname_вашего_vCS> --database-port 1433 -m <пароль_пользователя_admin@System-Domain>
  4. Исправить порт в конфигурационном файле SSO-сервера: C:\Program Files\VMware\Infrastructure\SSOServer\webapps\lookupservice\WEB-INF\classes\config.properties. Строка db.url=
  5. Перезапустить ОС с vCS.


Основной источник

PS: Помимо вышеописанного, мы предварительно поменяли порядок старта служб vCS (хотя скорее всего, это опционально):
     vCenter Single Sign On Service - from Automatic (Delay) to Automatic
     VMware vCenter Inventory Service - from Automatic to Automatic (Delay)
     VMware vSphere Profile-Driven Storage Service  - from Automatic to Automatic (Delay)
     VMwareVCMSDS  - from Automatic to Automatic (Delay)

Написать комментарий

Note to remember: SCSI Bus Sharing

Понедельник, 27 января 2014, 14:02

Довольно специфическая конфигурация -- подключение к двум ВМ одного виртуального диска (SCSI Bus Sharing). Используется, например для конфигурации CLuster-in-a-box.

Нерабочая конфигурация 1:
 - SCSI 0:0, Thin Disk - локальные диски с ОС каждой ВМ.
 - SCSI 0:1, Thick Disk - общий кластерный раздел.

Нерабочая конфигурация 2:
 - SCSI 0:0, Thin Disk - локальные диски с ОС каждой ВМ.
 - SCSI 1:0, Thick Disk - общий кластерный раздел.

Рабочая конфигурация:
 - SCSI 0:0, Thick Disk - локальные диски с ОС каждой ВМ.
 - SCSI 1:0, Thick Disk - общий кластерный раздел.

В документации Setup for MS Failover Clustering есть рекомендация выбирать тип диска "толстый" для загрузочных разделов, но к сожалению явно не указано, что вариант с Thin дисками совсем не заработает и будет выдавать невнятные ошибки.



Почему диск на отдельном виртуальном SCSI-контроллере (для которого Bus Sharing = 'None') не может быть динамическим -- логика неясна.

Источник: вопрос в комьюнити. Спасбо пользователю pzheber за скриншот.

1 комментарий

About vSphere Replication

Среда, 28 ноября 2012, 21:48

Технология vSphere Replication уже довольно хорошо известна и начинает понемногу использоваться в продуктивных системах. С выходом vSphere 5.1 механизм репликации был полностью отвязан от SRM и архитектурно значительно упростился:

  • Серверы VRMS и VRS были объеденены в один VR Appliance
  • VR Appliance больше не требует внешней БД
  • Один VR Appliance может обслуживать до 500 вм (ранее была неофициальная информация о 50-100)
  • Появилась возможность указывать определённый порт vmkX для трафика репликации (только в web-клиенте!)

Ниже некоторые особенности работы vSphere Replication:

1. Для снижения нагрузки на канал при первоначальной репликации виртуальных машин, на вторую площадку можно отвезти копии их vmdk-дисков. Важно помнить, что даже если вдруг офлайновые копии будет полностью идентичными, при запуске репликации на продуктивном массиве временно возрастёт нагрузка I/O на чтение. Дело в том, что при запуске репликации vmdk-файлы поблочно считывыаются и для каждого блока данных сохраняется значение его хеша. По данным значениям будут отобраны блоки, которые необходимо синхронизировать на этапе Full Sync.


2. Снапшоты создаёются только на второй площадке! На защищаемой площадке используется механизм Light-Weight Deltas (LWD). По заверениям инженеров VMware yикакого отношения к снапшотам и CBT он не имеет (иначе реплицируемые машины крайне сложно было бы бекапить средствами резервного копирования, использующими тотже CBT).


3. На удалённом сайте всегда существует непротеворечивая копия диска. Все изменения пишутся в redo-лог (снапшот). Когда истекает время, заданное параметром PRO для данной вм и на удалённый сайт приходит подтверждение, что все нужные блоки переданы (при загруженном канале сроки могут срываться) происходит коллапс дельта-диска и оригинального vmdk-файла. Только после этого создаётся новый снапшот.

4. Сердце vSphere Replication - механизм планирования передачи реплецируемых блоков. Именно он позволяет гибко выдерживать заданные значение RPO для машин, учитывая что нагрузка на каждую из них может быть разной в произвольный промежуток времени.

На рисунке схематично изображена передача данных для десяти вм (G1-G10). Некоторые реплицируются часто и мало (низкое значение PRO), некоторые - реже и их дельта значительно больше (больше PRO, частое изменение данных в госте). Нижняя полоска (Bandwith) наглядно демонстрирует насколько суммарно нагружен при этом канал передачи данных.

Заявляется что его движок ведёт некую статистику времени передачи данных в прошлый промежуток синхронизации и, соответсвенно, сколько предположительно потребуется для передачи всех данных в текущей итерации. При недостаточности канала репликации планировщик старается минимизировать отклонение от PRO для всех вм, без выделения приоритетных.

Написать комментарий

Removing orphaned Nexus

Пятница, 16 ноября 2012, 20:35

Сегодня коллеги озадачили вопросом: "Как вычистить из инфраструктуры vCenter некорректно удалённый виртуальный коммутатор Nexus 1000v"?

Не знаю, почему так случилось, но аплинки и машины были перенесены на другие коммутаторы, модули VMS и VEM уже удалены, но в инфраструктуре объекты всё ещё существовали:



Когда-то я уже удалял из базы vCenter машину-призрака, поэтому решили пойти по тому же пути:

0. Делаем бекапы всего что необходимо!
1. Cтопим службу VMware VirtualCenter Server.
2. В Management Studio идём: <SQL север> ->Databases -> <имя БД для vCenter> -> Tables -> dbo.VPX_VDS. В контекстном меню Edit top 200 Rows. Удаляем строку с общими параметрами Nexus'а.
3. Аналогично удалению виртуалки необходимо удалить сам коммутатор и все всязанные объекты в таблице: Tables -> dbo.VPX_ENTITY. Ищем по имени объект самого свича и обращаем внимание на его ID. Далее в таблице находим все связанные объекты (с темже ID в колонке PARENT_ID) и удаляем сначала их. Последним удаляем строку с самим родительским объектом - коммутатором.


4. Ребутаем службу SQL Server для уверенности. И стартуем службы VMware VirtualCenter Server и все зависимые.

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

Источники:

http://kb.vmware.com/kb/1026009

http://frankdenneman.nl/networking/removing-orphaned-nexus-dvs/

Написать комментарий
howto  kb  vSphere 5  

Create a snapshot with large virtual disk

Пятница, 16 сентября 2011, 14:19

Короткая заметка, в качестве напоминания.

В предыдущих версиях vSphere магическое число 2TB-512bytes ограничивало нас во всём: vmdk-файлы (для максимального размера блока), RDM, datastore size.

Для vSphere 5 и VMFS 5 ограничения несколько изменились:
    Max Volume size    — 64TB
    pRDM                    — 64TB
    vmdk-файл, vRDM — 2TB-512bytes (даже для датасторов, обновлённых с VMFS 3 на VMFS 5)

Так вот, нужно учитывать один момент, создавая диски размером ровно или близким к 2TB. Всё, что связано со снапшотами, для них может не заработать:



То есть, основная проблема может возникнуть при резервном копировании такого диска. И выясниться это может уже когда данные будут залиты а то и когда будут уже в продакшене :)

Полезные ссылки:

kb 1012384

vsphere-50-configuration-maximums.pdf

Вопрос в комьюнити

Написать комментарий
⇤ Последнее
← Позже 1-я страница Раньше →