ESX 4.1 нормально поддерживает диски от ESX 3.5

Приятной неожиданностью было при тестовом перезде LUN-ов:

Отзеркалировал луны презентованные ESX 3.5 на луны таких же размеров, и подал копии "боевых" лунов на ESX 4.1 после чего на хосте в разделе Configuration -> Storage -> Datastorage диски не появились, но были видны как LUN-ы на в Configuration -> Storage Adapters, внимание тут кажется что ESX 4.1 поведет себя привычным образом при нажатии на "Add Storage..." (в Configuration -> Storage -> Datastorage), типа покажет, что видит все луны и предложит их отформатировать как ранее не использовавшиеся (галки "Scan for New Storage Devices" и "Scan New VMFS Volumes" были выставлены при пересканировании естественно, но VMFS тома не обнаруживались всё-равно).

Все, на самом деле будет не так:
Жмем "Add Storage..." далее выбираем "Disk/LUN", и..., вот тут самое интересное:



видим, что они насамом деле понимаются с файловой системой... Next



а тут, самый ожидаемый выбор, что делать с обнаруженной сигнатурой...





После этого хранилище становиться доступным



Жмем "Browse DataStore" и добавляем гостя (виртуальную машину) в Inventory, который уже был на хранилище. Все настройки машины сохранены, вплоть до сети(vmx-файл никто не менял же ))

Не IOPS-ами едиными

Странные вещи иногда происходят:

Внезапно перебежал кластер CCR MailBox Exchange 2007 с одной ноды на другую, поначалу было подумал что причина в изменении конфигурации на одной из SAN фабрик, -я фабрика SAN коммутаторов при этом не менялась и была доступна, так как софт обеспечивающий multipath-инг в SAN показывал 4 пути до диска.

По быстрому зайдя на диски презентованные с СХД (системы хранения данных) на обоих нодах попытался их открыть и на той ноде с которой пошло убегание - задержка была очень большой, видимо какое то влияние при перестроении одной фабрики было...
Предположительно что это не корректно отработал EMC PowerPath версии 5.3 build 311

Усомнило:
Далее посмотрев логи на ставшей пассивной ноде обнаружил, что отваливались обе сети:
Event Type: Warning
Event Source: ClusSvc
Event Category: Node Mgr
Event ID: 1123
The node lost communication with cluster node 'MBS-01' on network '_LAN-TEAM'.

и

The node lost communication with cluster node 'MBS-01' on network 'Interconnect-Cabel1'.

а дальше понятно:
Cluster service was terminated as requested by Node 2.

это потому что был доступен кластерный File Whitness Share

Да и позже вспомнил, что недавно устанавливал на все Exchange 2007 сервера Update Rollup 1 for Exchange Server 2007 Service Pack 3, который как раз не был установлен на узел с которого кластер сбежал...

Есть поле для размышления...

Позднее стала ясна причина всего этого оказалась что SPA и SPB - сторадж процессоры системы CLARiiON CX4-120 перестали справляться с нагрузкой, поданной на них, это стало очевидно после нарезки луна для одного из серверов и начала переноса на него данных объемом половина терабайта. При этом PowerPath показывал большую очередь к диску и текущие IO порядка 20-50 - переброс с одного процессора на другой (Trespass...) не дал результата, реальная скорость копирования достигала порядка 10 мегабайт в секунду - с диска на диск внутри сервера - с разных систем хранения. Вспомнил, что у было настроено 14 синхронных зеркалирований между системами хранения, 6 из которых были временными. Временные зеркалирования отключил, на системах, нагрузка по вводу/выводу на PowerPath Monitor сразу подскочила до 800-1300 операций в секунду (диск был на RAID5 и состоял из 8 SATA-дисков):



Скорость была более 15Гб в минуту

Также, на всякий случай, поотключал кэши чтения и записи на некритичных лунах СХД.

SteelEye DataKeeper замена MirrorView и EMC Cluster enabler под Windows!!!

При наличии SteelEye DataKeeper под Windows никакой MirrorView и EMC Cluster enabler с использованием SAN будет просто не нужен.

http://www.steeleye.com/DataKeeper_69.htm

http://blogs.technet.com/b/vm/archive/2008/11/16/steeleye-datakeeper-_2d00_-build-hyper_2d00_v-cluster-without-san.aspx

Галактики ERP пробный переезд с 32-битной платформы на 64-битную

Имели продакшн сервер HP DL 580G5, 32G RAM, и дисками с SAN, с одной базой Галактики ERP в двухуровневой архитектуре, размер базы без транзакционных журналов, но с журналом базы галактики составлял 70Гб, всё это было на Windows 2003 Enterprise 32bit + SQL 2005 Enterprise 2005 32-bit.

Подняли виртуальную машину Windows 2003 Standart 64-bit с достаточным объемом дискового пространства, поставили SQL 2005 64bit и обновили его до версии соответствующей версии SQL на продакшн сервере, после чего восстановили базу мастер и боевую базу, а также рабочий каталог галактики - клиентской части и support.

Далее был выкачан новый дистрибутив Галактики ERP(потом, как выяснилось - это было сделано зря, лучше бы использовали старый), поскольку мы ставили достаточно давно, а обновлений (patches) на ресурсные файлы за пару лет было накачено на ERP огромное множество, благо под цели тестирования есть ещё 2 тестовых сервера, где крутиться около 5 тестовых баз - клонов производственной, для тестирования различных обновлений (patches) и внедрения новых АРМов(автоматизированных рабочих мест).

После установки не хотел нормально вязаться NAP-сервер с SQL (оба располагались на одном сервере) и клиентская часть (обычно клиентскую шару располагают там же) тоже не пускалась. Симптомы были очень странными - служба работала, порт 1997 слушался (смотрели утилитой CurrPorts), но telnet на порт не цеплялся ))), А также не могли подключиться через "Менеджер серверов и служб "Галактики"" - видимо по той же причини, что и не могли подключиться по telnet:



При сравнении dll-файлов на продакшн и тестовом сервере, выяснилось, что на тестовом вообще нет версии у файлов, - заменили библиотеки с продакшн, после этого перезагрузив - всё заработало, без перезагрузки никак не обошлось. (да и Internet Explorer Enhanced Security Configuration тоже надо отключать - не любят они друг друга)

Теперь осталось дело за "МАЛЫМ" - проверить программистскую часть о чем и было попрошено программистов(по-проверять проводки и т.п.).

Переключение аппаратно зеркалируемого диска сервера на пассивное плечо

Переключение аппаратно зеркалируемого диска сервера на пассивное плечо.
Аппаратное зеркало на CLARiiON CX4-120.

Условия:
Есть сервер Windows (EMC PowerPath + Navisphere Agent установлены, естественно), которому через SAN поданы диски одинаковой емкости, и настроена аппаратная синхронизация между ними (на дисковых массивах). т.е. на обной системе хранения есть активный LUN, и на другой тоже есть LUN, но пассивный, и происходит непрерывная репликация данных между ними.

Задача:
Переключиться на пассивный диск другой системы хранения.



Решение:
Предварительно, перед тем, как переключаться на зеркало, необходимо убедиться, что на дисковом томе, который располагается на этом LUN-е отсутствуют общие сетевые ресурсы - папки в общем доступе, если таковые имеются, то нужно запомнить их Permission на вкладе Share в свойствах, потому как их придется пересоздать, если мы не хотим перезапускать службу сервера.

Заходим в Navisphere Manager и делаем Promote на Secondary Image LUN-е:



в итоге получаем:



и нужно сделать на нем "Reactivate Disk".

После этого том становиться доступным, но сетевые шары, оказываются пустыми, далее здесь есть два пути:
1.Перезапуск службы сервера.
2.Но пункт 1 противопоказан, если у нас есть ещё много различных сетевых папок на этом сервере с активно работающими пользователями. Перезапуск службы сервера их всех отключит просто. Поэтому нужно пересоздать шару с теми же правами на сетевой ресурс, а права NTFS - вообще не трогать, так как они сохраняются.

Перенос раздела на другой диск без остановки сервиса

В прошлом году при запуске двух CLARiiON-ов CX4-120 на соседнем предприятии очень удивило то, что некоторые опытные администраторы Windows систем не знают, как можно перенести раздел или увеличить пространство на существующем разделе без перезагрузки сервера и остановки сервисов данные которых расположены на дисках требующих увеличение раздела.
Естественно, для подобного рода операций необходимы некоторые условия:
1.Наличие достаточного свободного пространства для увеличения/переноса раздела.
2.Тип Дисков должен быть как минимум динамическим(ИМХО)(Удобнее всего использовать сеть SAN).

Правда известный преподаватель с курсов по CLARiiON(http://microinform.ru/emc/MR-1CP-CHIMSV.htm и http://microinform.ru/emc/MR-1CP-MVSCSP.htm) против такого подхода и говорит что есть diskpar - пользуйтесь лучше им. Хорошо что есть оба варианта, просто вариант с diskpar более не удобен на мой взгляд.

Собственно будем использовать программное зеркало Windows - в этом нет никакого секрета, да, получим небольшую нагрузку на процессор и платы ввода/вывода, но это не так существенно по сравнению с тем, что может быть, если будет остановка важного, если не сказать критического сервиса для предприятия. К тому же нагрузка на процессор не даст ощутимого эффекта (Degrade Perfomance) для остальных программ и служб в целом для системы с учетом современных серверов и процессоров(взять, для примера, те же самые HP DL 360).

Собственно в оснастке compmgmt.msc имеем:



где верхний G и нижний - это один том - просто плечи одного зеркала, при удалении одного из них том G будет оставаться работоспособным.

Собственно зеркало для тома создается правой кнопкой на томе Add mirror... где далее будет предложено выбрать из доступных сводных мест на дисках.

Благодаря этой возможности нам удалось, в связи с перегревом в серверном помещении из-за каскадного отказа кондиционеров(их внешние блоки тоже не любят сильной жары и прямых солнечных лучей), за сутки перенести 4 критических сервера с данными из одной серверной в другую, разделы были путем частично программного, частично аппаратного зеркалирования перенесены с одной системы хранения на другую, а сами сервера физически были перенесены и подключены в течение 2х часов.

Проблема с общим диском у нод ESX - нет проблемы

Суть проблемы собственно:

Диск подан через SAN но ноды кластера (HA и DRS) не могут переместить на него виртуальные машины, даже если Гостевая ОС в offline.

При этом при ближайшем рассмотрении оказалась картина немного другая:

У Обоих нод, диск не сконфигурирован как Storage, т.е. WWN его виден на серверах, при этом, если смотреть хранилища на кластере, через меню Databases (там где Inventory и т.д.), то там хранилище присутствует, мало того, на нем располагается один из шаблонов виртуальных машин. но при просмотре самого хранилища - на нем вообще нет ни одного файла.

После удаления шаблона из Inventory хранилище само пропало. (ESX 3.5).

Добавил отформатировал и добавил его заново.

Предполагаю что глюк был связан с тем, что ранее менял тип RAID-а для этого дискового ресурса на CLARiiON, и когда отключал, просто не заметил что в инвентори хранилище присутствует, а оно присутствовало, скорее всего, по причине шаблона. Шаблон думал что он на хранилище, а хранилища не было уже; и, когда стал подавать его заново на ноды, просто не добавил как хранилище, а только презентовал через SAN.

Просто добавил его заново.