Рассказ 1. ВАС'овское кольцо или ГеоЦод.
Оригинал взят у alexanderberko в Рассказ 1. ВАС'овское кольцо или ГеоЦод.
История данного проекта на мой взгляд, для гос. организации просто невероятна. На момент 2012-2013 года, когда начали задумываться об объединении площадок не просто в ЦОД, а в единый, территориально разнесённый отказоустойчивый геоцод, отвечающий всем требованиям безопасности и функциональности (нужны были одни и те же виланы по всем площадкам (если вкратце, то ножен один L2 по площадкам), один SAN на FC и другие требования, необходимые для работы нормального кластера), такой реализации мы найти не смогли . Мы готовы были связаться с любыми коллегами, что бы поделиться опытом и по возможности избежать каких-то костылей, так как шаг влево или шаг вправо обходится весьма дорого, а простоя допустить просто не возможно (не говоря о потере данных). Поискав по всем партнерам и опросив всех менеджеров по Vmware, Microsoft, IBM, Hitachi мы остались без ответов. Были примеры различных отдельных реализаций, много примеров распределенных сетей (Ethernet), но все они работали с L3 и как правило без сквозного проброса между площадками. А о реализации подобного кластера на vmware или Hyper-V вообще тишина. Многие коллеги когда слышали, что мы намереваемся сделать, крутили пальцами у виска и говорили, что это не возможно, что это не будет работать и так ни кто не делает. Как же было приятно смотреть на них чуть позже, когда они сначала с недоверием, а потом и увлечением включались в проект. Конечно, были и те, что отказывался верить и пытался вставлять "палки в колеса", говоря что ничего не получится, с такими коллегами мы расставались, ведь нам нужны только лучшие!
Какие основные задачи мы решали и какие надежды возлагали?
Это только часть тех задач, которые можно было решить. Конечно, нам предстояло навести порядок в сетевой адресации, наименованиях, номерах виланов, своих привычках и всему тому, что называется местечковость. Но, порядок есть порядок, убираться мало кто любит, а затевать генеральную уборку, так вообще единицы :) Засучив рукава, принялись за работу.
Основа.
В 2011 году, по всем 113 объектам, мы выполнили поставку типовых решений для серверной, рассчитанные на средний офис (~150-300 сотрудников, без VDI) в него вошли Bladecenter System E и X (на борту 2 FC свитча Brocade и 2 Ethernet Nortel BNT 2/3 (многие лета жизни ему любимому)) и несколько полок Hitachi AMS 2100
Внутри VMWare vSphere 5. Данную типовую поставку было решено взять за основную, На отдалении, задача выглядела просто, нужно было объединить все гипервизоры в несколько кластеров, предоставив одни луны и виланы, разобраться с автоматической балансировкой нагрузки на СХД, решить проблемы с STP, обеспечив каждый объект отказоустойчивыми (как минимум 2-я) каналами связи. тю, делов то )))
Про объекты
Предстояло объединить 6 стоек, разнесённых по Москве. Расстояние между объектами укладывается в 10 км, максимальное расстояние до 20 км. На каждом объекте есть свой отдел ИТ, с разной компетенцией, но есть. Между 3 из 6 объектов, оптика уже была проложена и даже изредка, бегал какой никакой трафик.
Сеть Ethernet.
Тут началось интересное. После аудита, стало понятно, что многие любят использовать первые номера виланов, сети кое-где до сих пор пересекаются, а маски далеки от /24. Fixed. Вендором решили взять компанию с не благозвучным для русскоговорящего человека названием Huawei(Huawei WDM OptiX OSN 1800).
Возможности и стоимость оборудования данной компании полностью отвечали нашим критериям, да и ребята крайне контактные. Вообще, после работы с данными коллегами, у нас остались только позитивные ощущения, суппорт быстро отрабатывал, а при необходимости, очень быстро писали необходимые патчи. Конечно, не обходилось без проблем. Например, долгое время оптимизировали настройки каналов, так как то fc свитчи не могли синхронизироваться, то луны отваливались то 3 то 10-е.
Потом, когда все нормально отработало пару дней, полетели невероятные проблемы. Тайминги начали расти на пустом месте. Бессоных 2 или 3 дня, а как результат, сбойная sfp-шка.
Но, наконец-то все разрешилось, альясы прописаны, зоны прогружены, фабрики работают. В начале проекта, я думал, что основные проблемы будут как раз в SAN, ошибся.
Nortel BNT 2/3 - Это проклятье. Это чистое проклятье.
Менять свитчи на что-то нормальное не представлялось возможным, так что нужно работать с тем, что есть. Первое что выяснилось, у нас нет возможности работать
Я недооценил Nortel. От этих свитчей требовалось малое, обеспечить связь с локальной инфраструктурой объекта, поднять и держать до 30 виланов и маршрутизировать локальный трафик в местную сеть. Первый fail был с STP, nortel предлагает 3 варианта:
1. RSTP
2. PVRST
3. MSTP
Вот тут и началось. PVRST отпал по отсутствию лицензии, купить которую оказалось не возможно или ну очень проблематично. С RSTP началось такое, что просто трудно сказать, сеть штормило просто ужасно. Мы сломали всю голову, оказалось все тривиально. Нортель глючит. Мы стали откатываться по прошивкам, вроде подобрали одну более ли менее рабочую, но увы, она оказалась на столько старой, что мы получили просто уйму других глюков. Пришлось переходить на MSTP. Перевели huawei, построили дерево, вроде все ОК. Да вот сейчас! Нортель наотрез отказался поклоняться китайцам, всяко демонстрируя свою непокорность. Опять пошли скакать по прошивкам, опять начали перебирать настройки. Но увы, пришлось сдаться и сделать один из нортелей рутом. Передохнули. запустились, работает. Начали подключать второй линк и тут началась чертовщина. Пакеты теряются самопроизвольно, нортель стал показывать включённые линки там, где были пустые порты! Я сначала не поверил своим глазам, думаю, ну перепутал, с кем не бывает, проверил, нет, подключены только 1-е два порта, но эта зараза, показывает, что включены то 5, то 6! Проблема оказалась очень интересной, совершенно независящие настройки внутренних портов. Если включить, то проблема пропадала. Какие именно уже не помню, но поведение было следующим, лезвия видели на своих портах кольцо и блокировали порты, оба. Писали в IBM, открывали кейсы, говорили с менеджерами. Всё в пустую, они признали ошибку, но писать патч отказались, сославшись на то, что для nortel они ничего делать не будут. Так и стоит до сих пор левые настройки на внутренних портах, костыль, но работает. В предпоследние дни перед запуском, мы с Андреем Курбатовым в прямом смысле жили на работе, перебирая различные варианты и подбирая оптимальные настройки.
Эту фотографию я сделал в тот вечер 29 ноября, написав
В общем и целом успех! 6 площадок, 12 свитчей и распределённая инфраструктура по Москве сделала большой, первый и единый вдох..
Мы все выдохнули, предстояло идти дальше.
SAN и SVC
Большой головной болью, была проблема синхронизации полок и предоставление отказоустойчивого виртуального луна. По сути, нужно было создать пулы из RAID, где вместо дисков будут полки на разных площадках. Тогда, данную задачу решало только решение от IBM, а именно SVC.
Нужно было объединить 2 ноды по 2 сервера в каждой ноде на разных площадках, выбрав оптимальное географическое положение. Проблема заключалась в том, что система ни как не хотела синхронизироваться, пулы разваливались и данным постоянно приходилось перезаписываться при восстановлении. Причем, восстановление не происходило автоматически, требовалось вмешательство. Проблема была выявлена Опять тесты, опять патчи, опять тюнинг. Наконец, все настройки выставлены, и гипервизор увидел свои первую распределённую дисковую систему и началась большая миграция данных.
Виртуализация.
Я люблю vmware и считаю, что это лучшее технологическое решение для инфраструктур, если используется для работы в корпоративном сегменте. Но, каждый раз, планируя архитектуру того или иного решения, я очень внимательно изучаю все конкурентные предложения, и только взвесив все плюсы и минусы, делаю выбор. Так как мы строили не Web ферму, то выбор стоял между Hyper-V, Citrix и VMWare. У каждого из этих решений, есть свои несомненные плюсы и минусы и нельзя говорить о безоговорочной победе одного из вендоров. Все ситуации уникальны. На тот момент, vmware бесстыже вырывался вперёд, оставляя остальных нервно курить в сторонке. При планировании данной архитектуры, я учитывал следующие основные возможности:
Система была выбрана, а учитывая то, что на блейдах уже была развернута (vsphere 4.1 и 4 esx), то оставалось решить лицензионные вопросы и провести обновление системы. Конфигурация представляла из себя пару кластеров, разбитые на пулы, vMoution, Storage vMoution и другие актуальные нужные фичи.
В итоге, у нас получилась отличная распределённая сеть Ethernet и SAN, система переживала выключение нескольких площадок, сама поднималась и восстанавливалась, виртуальные машины мигрировали по разным площадкам, а система управления питанием управляла включением и отключением блейдов и серверов, оптимизируя инфраструктуру перед ростом нагрузки и в ночное время суток. Выход дисков и один раз полки в СХД так же отработали на ура. В общем и целом, проект удался, и стал основой для других, не менее интересных проектов.
История данного проекта на мой взгляд, для гос. организации просто невероятна. На момент 2012-2013 года, когда начали задумываться об объединении площадок не просто в ЦОД, а в единый, территориально разнесённый отказоустойчивый геоцод, отвечающий всем требованиям безопасности и функциональности (нужны были одни и те же виланы по всем площадкам (если вкратце, то ножен один L2 по площадкам), один SAN на FC и другие требования, необходимые для работы нормального кластера), такой реализации мы найти не смогли . Мы готовы были связаться с любыми коллегами, что бы поделиться опытом и по возможности избежать каких-то костылей, так как шаг влево или шаг вправо обходится весьма дорого, а простоя допустить просто не возможно (не говоря о потере данных). Поискав по всем партнерам и опросив всех менеджеров по Vmware, Microsoft, IBM, Hitachi мы остались без ответов. Были примеры различных отдельных реализаций, много примеров распределенных сетей (Ethernet), но все они работали с L3 и как правило без сквозного проброса между площадками. А о реализации подобного кластера на vmware или Hyper-V вообще тишина. Многие коллеги когда слышали, что мы намереваемся сделать, крутили пальцами у виска и говорили, что это не возможно, что это не будет работать и так ни кто не делает. Как же было приятно смотреть на них чуть позже, когда они сначала с недоверием, а потом и увлечением включались в проект. Конечно, были и те, что отказывался верить и пытался вставлять "палки в колеса", говоря что ничего не получится, с такими коллегами мы расставались, ведь нам нужны только лучшие!
Какие основные задачи мы решали и какие надежды возлагали?
- Оптимизация использования имеющихся ресурсов
- Последующее снижение стоимости владения
- Повышение отказоустойчивости работы серверов, сервисов
- Расширение предоставляемых инфраструктурных возможностей и решений по объектам
- Унификация используемых серверных решений
- Возможность централизованного администрирования
- Возможность децентрализации точек отказа
- Внедрение стандартизированных решений
- Регламентация текущих решений
- Ровнамерное распределение нагрузки на дисковые подсистемы. Система должна сама выбирать место храния данных (SAS или SATA), в зависимости от размера и частоты использования.
- Резервирование
- Возможность автоматизированного восстановления и миграции ресурсов.
Это только часть тех задач, которые можно было решить. Конечно, нам предстояло навести порядок в сетевой адресации, наименованиях, номерах виланов, своих привычках и всему тому, что называется местечковость. Но, порядок есть порядок, убираться мало кто любит, а затевать генеральную уборку, так вообще единицы :) Засучив рукава, принялись за работу.
Основа.
В 2011 году, по всем 113 объектам, мы выполнили поставку типовых решений для серверной, рассчитанные на средний офис (~150-300 сотрудников, без VDI) в него вошли Bladecenter System E и X (на борту 2 FC свитча Brocade и 2 Ethernet Nortel BNT 2/3 (многие лета жизни ему любимому)) и несколько полок Hitachi AMS 2100
Внутри VMWare vSphere 5. Данную типовую поставку было решено взять за основную, На отдалении, задача выглядела просто, нужно было объединить все гипервизоры в несколько кластеров, предоставив одни луны и виланы, разобраться с автоматической балансировкой нагрузки на СХД, решить проблемы с STP, обеспечив каждый объект отказоустойчивыми (как минимум 2-я) каналами связи. тю, делов то )))
Про объекты
Предстояло объединить 6 стоек, разнесённых по Москве. Расстояние между объектами укладывается в 10 км, максимальное расстояние до 20 км. На каждом объекте есть свой отдел ИТ, с разной компетенцией, но есть. Между 3 из 6 объектов, оптика уже была проложена и даже изредка, бегал какой никакой трафик.
Сеть Ethernet.
Тут началось интересное. После аудита, стало понятно, что многие любят использовать первые номера виланов, сети кое-где до сих пор пересекаются, а маски далеки от /24. Fixed. Вендором решили взять компанию с не благозвучным для русскоговорящего человека названием Huawei(Huawei WDM OptiX OSN 1800).
Возможности и стоимость оборудования данной компании полностью отвечали нашим критериям, да и ребята крайне контактные. Вообще, после работы с данными коллегами, у нас остались только позитивные ощущения, суппорт быстро отрабатывал, а при необходимости, очень быстро писали необходимые патчи. Конечно, не обходилось без проблем. Например, долгое время оптимизировали настройки каналов, так как то fc свитчи не могли синхронизироваться, то луны отваливались то 3 то 10-е.
Потом, когда все нормально отработало пару дней, полетели невероятные проблемы. Тайминги начали расти на пустом месте. Бессоных 2 или 3 дня, а как результат, сбойная sfp-шка.
Но, наконец-то все разрешилось, альясы прописаны, зоны прогружены, фабрики работают. В начале проекта, я думал, что основные проблемы будут как раз в SAN, ошибся.
Nortel BNT 2/3 - Это проклятье. Это чистое проклятье.
Менять свитчи на что-то нормальное не представлялось возможным, так что нужно работать с тем, что есть. Первое что выяснилось, у нас нет возможности работать
Я недооценил Nortel. От этих свитчей требовалось малое, обеспечить связь с локальной инфраструктурой объекта, поднять и держать до 30 виланов и маршрутизировать локальный трафик в местную сеть. Первый fail был с STP, nortel предлагает 3 варианта:
1. RSTP
2. PVRST
3. MSTP
Вот тут и началось. PVRST отпал по отсутствию лицензии, купить которую оказалось не возможно или ну очень проблематично. С RSTP началось такое, что просто трудно сказать, сеть штормило просто ужасно. Мы сломали всю голову, оказалось все тривиально. Нортель глючит. Мы стали откатываться по прошивкам, вроде подобрали одну более ли менее рабочую, но увы, она оказалась на столько старой, что мы получили просто уйму других глюков. Пришлось переходить на MSTP. Перевели huawei, построили дерево, вроде все ОК. Да вот сейчас! Нортель наотрез отказался поклоняться китайцам, всяко демонстрируя свою непокорность. Опять пошли скакать по прошивкам, опять начали перебирать настройки. Но увы, пришлось сдаться и сделать один из нортелей рутом. Передохнули. запустились, работает. Начали подключать второй линк и тут началась чертовщина. Пакеты теряются самопроизвольно, нортель стал показывать включённые линки там, где были пустые порты! Я сначала не поверил своим глазам, думаю, ну перепутал, с кем не бывает, проверил, нет, подключены только 1-е два порта, но эта зараза, показывает, что включены то 5, то 6! Проблема оказалась очень интересной, совершенно независящие настройки внутренних портов. Если включить, то проблема пропадала. Какие именно уже не помню, но поведение было следующим, лезвия видели на своих портах кольцо и блокировали порты, оба. Писали в IBM, открывали кейсы, говорили с менеджерами. Всё в пустую, они признали ошибку, но писать патч отказались, сославшись на то, что для nortel они ничего делать не будут. Так и стоит до сих пор левые настройки на внутренних портах, костыль, но работает. В предпоследние дни перед запуском, мы с Андреем Курбатовым в прямом смысле жили на работе, перебирая различные варианты и подбирая оптимальные настройки.
Эту фотографию я сделал в тот вечер 29 ноября, написав
В общем и целом успех! 6 площадок, 12 свитчей и распределённая инфраструктура по Москве сделала большой, первый и единый вдох..
Мы все выдохнули, предстояло идти дальше.
SAN и SVC
Большой головной болью, была проблема синхронизации полок и предоставление отказоустойчивого виртуального луна. По сути, нужно было создать пулы из RAID, где вместо дисков будут полки на разных площадках. Тогда, данную задачу решало только решение от IBM, а именно SVC.
Нужно было объединить 2 ноды по 2 сервера в каждой ноде на разных площадках, выбрав оптимальное географическое положение. Проблема заключалась в том, что система ни как не хотела синхронизироваться, пулы разваливались и данным постоянно приходилось перезаписываться при восстановлении. Причем, восстановление не происходило автоматически, требовалось вмешательство. Проблема была выявлена Опять тесты, опять патчи, опять тюнинг. Наконец, все настройки выставлены, и гипервизор увидел свои первую распределённую дисковую систему и началась большая миграция данных.
Виртуализация.
Я люблю vmware и считаю, что это лучшее технологическое решение для инфраструктур, если используется для работы в корпоративном сегменте. Но, каждый раз, планируя архитектуру того или иного решения, я очень внимательно изучаю все конкурентные предложения, и только взвесив все плюсы и минусы, делаю выбор. Так как мы строили не Web ферму, то выбор стоял между Hyper-V, Citrix и VMWare. У каждого из этих решений, есть свои несомненные плюсы и минусы и нельзя говорить о безоговорочной победе одного из вендоров. Все ситуации уникальны. На тот момент, vmware бесстыже вырывался вперёд, оставляя остальных нервно курить в сторонке. При планировании данной архитектуры, я учитывал следующие основные возможности:
- Система должна быть надёжной
- Система должна быть гибкой, иметь возможность легко и динамично изменяться под любые нужды
- Система не должна быть ресурсоёмкой.
- Система должна иметь интеграцию в AD и уметь работать как с пользователями, так и с группами.
- Система должна позволять очень гибкую работу с сетью (зеркалирование, проброс, работа с виланами и группами виланов и т.п)
- Система должна иметь web интерфейс
- Система должна быть легко масштабируемой
- В случае проблем, система должна иметь возможность работать до последнего
- Автоматическое распределение ресурсов и нагрузки
- Автоматическое управление питанием
Система была выбрана, а учитывая то, что на блейдах уже была развернута (vsphere 4.1 и 4 esx), то оставалось решить лицензионные вопросы и провести обновление системы. Конфигурация представляла из себя пару кластеров, разбитые на пулы, vMoution, Storage vMoution и другие актуальные нужные фичи.
В итоге, у нас получилась отличная распределённая сеть Ethernet и SAN, система переживала выключение нескольких площадок, сама поднималась и восстанавливалась, виртуальные машины мигрировали по разным площадкам, а система управления питанием управляла включением и отключением блейдов и серверов, оптимизируя инфраструктуру перед ростом нагрузки и в ночное время суток. Выход дисков и один раз полки в СХД так же отработали на ура. В общем и целом, проект удался, и стал основой для других, не менее интересных проектов.