Смена прошивки на SAN от IBM и Windows Server 2008 или танец с бубном

Не прошло и двух лет, как у нас, наконец-то, закончилась эпопея с нашим SAN.

Итак, дело в следующем. Три с половиной года назад мы приобрели комплект оборудования от IBM. Туда входили: SAN DS4700, Blade H с набором лезвий и ленточная библиотека TS3200.

На тот момент весь парк серверов у нас работал на Windows Server 2003 R2 и кое-где у нас стояли Windows 2000 Server. На SAN стояла прошивка 6.хх и использовался Storage Manager 9.x, который обеспечивал RDAC (multipath) драйверами Windows 2003.

Через какое-то время появился Windows 2008, который я решил попробовать и обнаружил, что RDAC драйверов от IBM для этой системы нет, и что самое интересное – и не планируется. Что для этой системы уже используется другой тип архитектуры драйверов, для которой нужен IBM Storage Manager 10.x, который, в свою очередь, требует прошивки 7.х. Когда я пошел качать эту самую прошивку, то получил предупреждение, смысл которого сводился к тому, что переводить систему с данными с 6.х на 7.х должен кто-нибудь из представителей IBM и никак иначе. Я, конечно же, связался с теми, кто нам ее продавал и … и получил ответ, который сводился к тому, что обновить-то ее могут, но вот гарантировать то, что данные останутся после прошивки никак не могут, максимум, что возможно – гарантия того, что “железо” оживет.

Я просто обалдел от такой вот новости. Бэкапы – это, конечно же хорошо, но на этом SAN кроме файлов живет еще куча загрузочных дисков от серверов, включая тот сервер на котором живет бэкап. Плюс к тому, суммарный объем информации таков, что сам по себе бэкап занимает более двух суток. Т.е. только готовиться нужно двое суток, а потом еще обновлять! Такое время простоя просто невозможно в нашей компании. А если восстанавливать нужно?

В общем – процесс встал, тем более, что по нашей информации, в нескольких местах были проблемы при обновлении. Но необходимость в нем не отпала, время-то идет, 2008 Server внедрять никто и не планировал, но уже вышел 2008 R2, а на него-то уже переход планировался. Мы стали искать другие компании, которые бы взялись за это. В конечном итоге, за это решил взяться Авалис. Вначале у них тоже было несколько шапкозакидательское настроение – типа “нефиг делать”, и данные куда-то перепишем и т.д. Потом, когда задача была сформулирована полностью, энтузиазма у них поубавилось и они на некоторое время пропали.

В конечном итоге было решено сделать следующее: они предоставляют нам во временное пользование еще одну систему хранения данных, на которую мы перепишем как файлы, так и загрузочные разделы с нашей, затем мы тестируем загрузку с альтернативной SAN, и если тест проходит нормально, то обновляем наш SAN. Если все пройдет хорошо, то стираем данные с их оборудования и отдаем его обратно. В случае проблем работаем с их оборудования до восстановления нашего и возврата данных обратно.

Т.о. дело стало за этим самым оборудованием, причем таким, чтобы на нем места хватило. Ну и мы хотели договор, по которому они несут ответственность за сроки простоя, за сохранность данных и последующее их уничтожение на своем оборудовании. Это оказалось одним из самых проблемных моментов, т.к. гарантировать-то не очень хочется! Все это вызвало увеличение суммы контракта в два раза и “битву” между нашими юристами, которая заняла наверное месяца 3. В конце концов договор был готов и заключен. Не могу сказать, что он на 100% меня устраивал, т.к. компенсировать потенциальные потери в полном объеме исполнитель таки отказался. В итоге сошлись на компенсации в размере контракта и неограниченном по времени использовании резервного оборудования в случае проблем.

Техническая часть же планировалась следующим образом: в начале недели нам привозят оборудование, мы его подключаем к нашей SAN, делаем диски и переписываем туда с помощью robocopy все файлы с ACL списками. Затем, с помощью того же robocopy, в течении недели мы синхронизируем изменения и к субботе, т.е. дню обновления, мы получаем практически идентичные копии, которые в субботу же, за короткий промежуток времени окончательно синхронизируются. Тогда же, планировалось перелить с помощью внутреннего функционала SAN загрузочные разделы и разделы с Exchange или другими базами. Но, посмотрев на быстродействие, мы выяснили, что на копирование разделов с Exchange нам понадобится от 30 и до 40 часов!

В конечном итоге, мы решили, что остановим Exchange и перепишем базы и логи транзакций у Exchange вручную, т.к. они занимали 20-25% от размера раздела, что даст нам большую экономию по времени.

Большинство серверов было выключено и сам процесс был запущен в пятницу после 20:00. Большинство разделов скопировались без проблем, но парочку, причем из наиболее важных, отказывались копироваться с малопонятной ошибкой. И тут сработал мой турецкий админский бубен! Да, можно смеяться, но 30-40 минут, два раздела с 3-й полки корзины копироваться отказывались, а затем Рухлан взял мой бубен и провел небольшое шаманское выступление. Что вы думаете – через 5 минут та же процедура прошла!!!

Был еще момент с одним из серверов приложений. Для того, чтобы проводить переход, нужно было на всех серверах убрать старые драйвера, т.е. удалить Storage Manager 9.x, и на всех серверах, кроме одного эта процедура прошла штатно, зашел, запустил анинсталл, перезагрузился и все. Но вот на одном эта процедура зависала на каком-то из этапов. После перезагрузки сервер вообще отказывался грузиться, но если по F8 его остановить и выбрать “last goon known configuration”, то все возвращалось на место, вместе с драйвером. И я уже думал, что придется плюнуть на этот сервер и быстренько его переустанавливать. Но тут я получил совет от Саши, который предложил попробовать удалить его из-под Safe Mode. И что бы вы думали? Он удалился!

В субботу мы закончили синхронизацию и запустили процесс обновления. Сам процесс описывать смысла нету, нужно просто запустить набор обновлений, который обновит ПО в разных частях SAN по очереди.

Так что теперь, заканчиваю перевод серверов на Windows 2008 R2 и начинаю внедрение виртуализации!