Skip navigation

Источник: Nice vmkfstools feature for Extents


Задача по устранению проблем, возникающих с экстентами (extent), всегда была весьма трудной. Не было простого способа узнать, какой экстент (а, фактически, это физический LUN или диск), входящий в состав VMFS тома, вышел из строя. Но, с выходом vSphere 5.0, ситуация в этом смысле кардинально поменялась. Теперь с помощью стандартной утилиты "vmkfstools" можно запросто вычислить, какой экстент в VMFS томе вышел из строя. Для примера, вот вам VMFS-5 том, который состоит из двух iSCSI LUN:

# vmkfstools -Ph /vmfs/volumes/iscsi_datastore/
VMFS-5.54 file system spanning 2 partitions.
File system label (if any): iscsi_datastore
Mode: public
Capacity 17.5 GB, 16.9 GB available, file block size 8 MB
UUID: 4d810817-2d191ddd-0b4e-0050561902c9
Partitions spanned (on "lvm"):
        naa.6006048c7bc7febbf4db26ae0c3263cb:1
        naa.6006048c13e056de156e0f6d8d98cee2:1
Is Native Snapshot Capable: NO

Теперь, если хотя бы один из экстентов, входящих в состав тома VMFS-5, выйдет из строя, то утилита "vmkfstools" выдаст нам соответствующее предупреждение, из которого будет легко понять, какое конкретно устройство находится в офлайне:

# vmkfstools -Ph /vmfs/volumes/iscsi_datastore/
VMFS-5.54 file system spanning 2 partitions.
File system label (if any): iscsi_datastore
Mode: public
Capacity 17.5 GB, 7.2 GB available, file block size 8 MB
UUID: 4d810817-2d191ddd-0b4e-0050561902c9
Partitions spanned (on "lvm"):
        naa.6006048c7bc7febbf4db26ae0c3263cb:1
        (device naa.6006048c13e056de156e0f6d8d98cee2:1 might be offline)
        (One or more partitions spanned by this volume may be offline)
Is Native Snapshot Capable: NO

Как видите, все достаточно легко и просто. Пользуйтесь.

Источник: SQL Server Rolling Patch Upgrade using Standby VM


Неплохой мануал на тему обновления SQL сервера с помощью запасной ВМ. Алгоритм достаточно простой и, вполне себе, логичный. Итак, вышло новое обновление для SQL сервера, и вам нужно с минимальным простоем в работе его обновить.

Небольшое отступление. В этом примере в качестве SQL сервера выступает виртуальная машина с тремя (3) дисками: "System", "Data" и "Log". Наверное, вы уже догадались, что основные манипуляции будут именно с виртуальными дисками "Data" и "Log".

В статье, а точнее будет сказать, в руководстве, приведенном как источник, чтобы обновить SQL сервер с минимальным простоем в работе, нам предлагают поступить следующим образом (всего 5 шагов и будет счастье):

Шаг 1: Configure standby VM

  • Создаем путем клонирования основной или, с помощью шаблонов, вторую (standby или, проще говоря, запасную) виртуальную машину (точную копию основной) с SQL сервером на борту.
  • Убедитесь в том, что запасной SQL сервер настроен точно так же, как и первый (основной).
sql-1.png

Шаг 2: Patch standby VM

  • Обновляем запасной SQL сервер (применяем все необходимые патчи)
sql-2.png

Шаг 3: Hot remove SQL Server resources from primary

  • На основном SQL сервере отключаем все клиентские подключения к баз(е/ам) данных.

Сбросить все клиентские соединения можно путем отключения сетевого интерфейса.

  • Отсоединяем (detach) все базы данных от основного SQL сервера (sp_detach_db).
  • Переводим виртуальные диски "Data" и "Log" в автономный (offline) режим работы.
  • Используя vSphere Client, удаляем из основного SQL сервера диски "Data" и "Log".

sql-3.png

Шаг 4: Hot add resources to the SQL Server standby VM

  • Используя vSphere Client, добавляем на запасной SQL сервер "Data" и "Log" диски.
  • Используя "Disk Management", делаем диски "online" и монтируем их под нужными буквами.
  • Используя T-SQL команду sp_attach_db, присоединяем к запасному SQL серверу все БД.

sql-4.png

Шаг 5: Switch role

  • На запасном SQL сервере разрешаем сетевой трафик от приложений, путем включения vNIC.
  • Запасной SQL становится основным, и приложения начинают с ним взаимодействовать.
  • Теперь уже бывший основной SQL сервер можно обновить и "потушить" до следующего подобного обновления.

sql-5.png

Простой в работе SQL сервера у вас произойдет с 3-его по 5-ый шаг, но большинство приложений данный незначительный простой должны пережить, попросту переустановив соединение до SQL сервера и повторив ранее невыполненные запросы.