Blog of Khlebalin Dmitriy

(Записки из мира IT…)

Злой рок «VmWare». И снова траблешутинг.


Последние несколько месяцев «Варя» исправно выполняла свои основные функции: 24*7, высокая доступность, отказоустойчивость и прочие «кайфы», присущие при ее наличии.

Вообще в последнее время, судя по рассказам коллег из компаний интеграторов, виртуализация все интенсивней входит в нашу жизнь, все больше и больше компаний приходят к выводу, что содержать и обслуживать железные сервера экономически не выгодно, трудоемко и нецелесообразно. Думаю, еще через несколько лет мы всецело погрузимся в виртуальные облака. Но все это лирика, плодородная почва для маркетологов и PR служб представителей различных вендоров. Сейчас не об этом. Нас больше в данный момент интересует техническая сторона вопроса.

Здесь хочется отметить, что в  последнюю неделю траблы с «Варей» никак не покинут нас. Изначала отвалился vCenter, об этом я недавно писал здесь:

https://khlebalin.wordpress.com/2013/08/20/%D1%82%D1%80%D0%B0%D0%B1%D0%BB%D0%B5%D1%88%D1%83%D1%82%D0%B8%D0%BD%D0%B3-vmware/

это неприятно, но никак не критично для бизнеса, починили и «Слава Богу», но спустя пару дней мы столкнулись с по настоящему реальной проблемой для нас в данном случае: одна из виртуалок (самая важная, как на зло…-сервер бухгалтерии) уперлась в размер стораджа и встала «колом». Соответственно «варя» не долго думая перевела ее в режим обслуживания корректно попросив добавить места или смигрировать ее на другой сторадж. И все бы ничего, если бы было место, куда смигрировать. За последние годы эксплуатации «Вари» в различных конфигурациях, с таким развитием событий столкнулся впервые (так скажем это не типичный случай, подробно рассмотренный в траблешутинге или преподаваемый на курсах).

После проведенного расследования удалось восстановить картину событий и пути их решений:

Итак, в наличии 3 стораджа:

-1 сторадж-1ТБ (на нем как раз и крутилась злополучная виртуалка размером 750Гб, вроде 250Гб достаточный запас и для тонких и для любых дисков, при условии, что база SQL не растет гигантскими темпами ежедневно (у нас не растет).

-2 сторадж-1ТБ с другими виртуалками (свободно примерно 500Гб)

-3 сторадж-2,5ТБ с другими виртуалками (свободно в районе 300Гб, т.е более 10% как того требует мануал по «Варе»).

И вроде бы все стабильно и ничего не предвещало беды. Но как говорится в одном известном документальном сериале «Секунды до катострофы»: Катастрофы не случайны Они являются цепью критических событий…..

А критические события развивались следующим образом:

За пару дней до этого у нас «отвалился» vCenter, соответственно в тот день Veeam не смог корректно сделать настроенные бэкапы. vCenter починили, сделали бэкапы руками, все прошло в штатном режиме, но тот снепшот, который изначально у него не получился, он почему то не удалил, тем самым практически заняв все место на первом сторадже, виртуалка еще немного поработала, изыскивая для себя свободные ресурсы, и встала «колом». Почему не загорелся Alert о том, что мало места на сторадже, это тема отдельного разговора (об этом чуть позже).

Далее опишу пути решения из сложившейся ситуации. Так как мигрировать было некуда (как видим места на стораджах уже нет), решили руками удалить снепшот тем самым освободив место и просто стартанув машинку, так собственно и сделали. Снепшот из оснастки пропал но файлы со стораджа не удалились и места соответственно не добавилось. Появилось следующее сообщение:

vSphere: Virtual machine Consolidation Needed status

 

КВ от «Вмваре» в этом случае рекомендует нам делать следующее (я, чтоб не искать само КВ, приведу эту же рекомендацию в одном из блогов:

http://hostilecoding.blogspot.ru/2013/01/vsphere-virtual-machine-consolidation.html

Делаем все по инструкции. Обычно консолидация проходит достаточно долго (или в ходе консолидации возникает ошибка) ну, или занимает какое то время, может несколько минут, может больше, после чего файлы удаляются со стораджа. Но в нашем конкретном случае все произошло иначе: консолидация прошла достаточно быстро сообщив нам, что все «Саксес», место на сторадже освободилось, мы спокойно стартанули виртуалку, но увиденное повергло меня в оцепенение и бросило в нервную дрожь: Мы оказались, как раз на несколько дней назад, когда был сделан этот снепшот а не в сегодняшнем дне. Для бухгалтерии это был полный «АХТУНГ», а для нас «Расстрел за амбаром» (почему снепшот стал реальной машинкой, а не наоборот мы, так и не смогли понять). Далее Disaster Recovery Plan был вообще не затейливым, второй (он же резервный) дата центр  на текущий момент у нас отсутствует. Оставалась одна надежда: ночной бэкап Veeam (им мы как раз и перезаписали существующую виртуалку). Он и явился нашим спасательным кругом, но 5 часов работы бухгалтерии оказались все равно невозвратными, так как бэкап ночной, а с утра люди уже отработали 5 часов. И даже то, что внутри самой виртуалки, средствами SQL каждые 4 часа делаются свои бэкапы базы, для нас они тоже в данном случае, оказались недоступны. Но вроде все закончилось «относительно» благополучно: я как руководитель получил свой «орден Сутулова с занесением в грудную клетку», и потратил достаточно много времени для восстановления. Здесь понравилась отличная функция восстановления с помощью Veeam: когда при восстановлении можно сразу работать на сервере, что позволило поначалу медленно, но со временем все быстрее и быстрее обеспечить работу в данном случае бухгалтерии и не терять время.

 

По факту произошедшего, обратились в техподдержку Veeam с вопросом: Почему не удалился снепшот Вимом при неудачном бэкапе несколько дней назад?, получили ответ: что такое иногда случается, когда что-то пошло не так при бэкапе. И посоветовали нам скачать и поставить sp3 для veeam, который как раз исправляет эту ошибку, выглядит он вот так:

snap1

 

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

P.S. После апгрейда сервера Veeam при очередном бэкапе, кстати, нашел им же не удаленные снепшоты еще на паре серверов (что говорит нам о том, что заплатка работает), и я всем рекомендую не забыть поставить ее в ближайшее время если используете версию 6.5. Представители техподдержки 7-ю версию пока ставить не рекомендуют, так как много неисправленных багов на данный момент. Возможно версия 7.1, которая появится через пару месяцев, улучшит ситуацию с апгрейдом.

P.P.S. Здесь еще оставался вопрос: почему «Варя» не просигнализировала нам Алармом, что место на сторадже заканчивается и надо срочно что-то делать? Проверили все настройки всех Алармов, в данном случае нас интересует вот этот:

snap2

 

Открываем свойства и видим

snap3

 

Что на 75%  сторадж благополучно информирует нас, что есть такая проблема с местом и если нажать на кнопку:

snap4

 

Acknowledge Alarm

То тем самым, Вы соглашаетесь с тем, что Вы в курсе данной проблемы и данный Аларм вновь не появится до тех пор, пока размер виртуалки не станет менее 75%, а потом снова не увеличится. В нашем случае видать так и произошло, размер меньше не становился, а кто-то из админов ранее согласился с этим, поэтому никаких предупреждений вновь не последовало. С данным механизмом необходимо обходиться очень тонко или не соглашаться с утверждением просто так или увеличивать порог.

Мораль басни такова:

— Стоит чуть-чуть пустить сервера на «самотек», так рано или поздно получите «кулак дружбы», аналогично нашему. Ежедневный мониторинг-хорошая практика и привычка.

— Места на стораджах «Вари» не бывает много. Всегда есть, чем его занять.

— Обращайте внимание на мелочи и возможно тогда, цепь критических событий не произойдет.

Всем хорошей работы! 

Реклама

26.08.2013 - Posted by | vmware & hyper-v Infrastructure

Sorry, the comment form is closed at this time.

%d такие блоггеры, как: