Comments 17
Если эти серверы виртуальные – начинает работать Live Migration виртуальных машин и можете «на ходу» переводить задачи между ЦОДами
Live Migration между ЦОДами — в теории круто, на на практике слабо выполнимо. Уж больно колоссальные у него требования к пропускной способности сети даже при штатном запуске. А резко перетащить сотню виртуалок на другую площадку методом live migration вообще невозможно, это потребует сотен гигабит емкости между площадками. Проще уж застопить машину и переместить ее диски. А при постоянной репликации СХД и диски тащить не надо, просто подмапил LUN на другом гипервизоре и вперед. А при грамотном использовании балансировщиков падение одной площадки целиком может вообще не потребовать никаких телодвижений. Но такое редко удается сделать.
Ну и L2 DCI (безусловное требование для любых видов VM mobility) — нечто, от чего лучше держаться подальше, если только в нем нет абсолютной необходимости (а обычно ее нет). Не очень здорово даже когда один VLAN растянут на целый ЦОД.
ну если географически распределенный — это стойки в соседних комнатах с двумя 10Gb линками между блейдовыми свитчами…
но им надо отработать по схеме продавца: «запугивание, запугивание, решение, дорогое, очень дорогое решение, оооочень дорогое решение, сказка, блаженство.» через обратную призму этого статья выглядит полезной.
но им надо отработать по схеме продавца: «запугивание, запугивание, решение, дорогое, очень дорогое решение, оооочень дорогое решение, сказка, блаженство.» через обратную призму этого статья выглядит полезной.
> Live Migration между ЦОДами — в теории круто, на на практике слабо выполнимо
Почему нет? В указанном пункте диски уже единые между двумя ЦОД, так что переместить необходимо только данные в памяти вирт. машины — это единицы гигабайт.
А т.к. для организации полной репликации дисков и так используется канал уровня 8-10G, то прокинуть пару гигабайт там не проблема.
Когда я участвовал в строительстве распределенного ЦОД, у нас была темная оптика между площадками, 16 волокн. 4 штуки ушло под FC, еще 4 под Ethernet, 8 под холодный резерв (не считая более медленных vpn каналов через сторонних провайдеров на самый крайний случай)
Почему нет? В указанном пункте диски уже единые между двумя ЦОД, так что переместить необходимо только данные в памяти вирт. машины — это единицы гигабайт.
А т.к. для организации полной репликации дисков и так используется канал уровня 8-10G, то прокинуть пару гигабайт там не проблема.
Когда я участвовал в строительстве распределенного ЦОД, у нас была темная оптика между площадками, 16 волокн. 4 штуки ушло под FC, еще 4 под Ethernet, 8 под холодный резерв (не считая более медленных vpn каналов через сторонних провайдеров на самый крайний случай)
Да, расстояние было порядка 15-20 км, что бы не было рассуждений, что ЦОД за соседней стенкой :)
В указанном пункте диски уже единые между двумя ЦОД, так что переместить необходимо только данные в памяти вирт. машины — это единицы гигабайт.
Так и диски обычно не сказать чтобы большие… Диски статичны, в отличие от памяти.
Но спору нет, при наличии 40G езернета live migration единичных машин не проблема. Вопрос — в том распределенном ЦОДе на практике таскали рабочие машины между площадками?
Диски как раз самое большое и есть. Общий объем — единицы/десятки терабайт. Такое точно не реально переместить одномоментно. Но если хранилища у нас синхронизированы, то максимум, что нужно переместить — это память вирт.машины, что составляет на порядок меньше — единицы/десятки гигабайт, а не терабайт.
В крайнем случае, если машины на той площадке просто умерли — они запустятся на другой, перемещать вообще ничего не надо.
В то время виртуальные машины в организации не использовались.
Решалось средствами приложения/базы, тестовые аварии отрабатывало нормально.
В крайнем случае, если машины на той площадке просто умерли — они запустятся на другой, перемещать вообще ничего не надо.
В то время виртуальные машины в организации не использовались.
Решалось средствами приложения/базы, тестовые аварии отрабатывало нормально.
Ну и L2 DCI (безусловное требование для любых видов VM mobility) — нечто, от чего лучше держаться подальше, если только в нем нет абсолютной необходимости (а обычно ее нет). Не очень здорово даже когда один VLAN растянут на целый ЦОД.
Тем не менее, такой тренд есть. И судя по тому, сколько усилий в этот направлении тратят производители сетевого оборудования и платформ виртуализации, функционал востребован заказчиками.
Касательно Live Migration между ЦОД.
Если клиент задумывает о миграции между ЦОД, то однозначно у него будет некая кластеризированная СХД с полностью реплицированной информацией. Иначе нет смысла мигрировать в другой ЦОД при Disaster Recovery. Если мигрировать в другой ЦОД для выполнения там вычислительных операций, а хранилище иметь в начальном ЦОДе, то вариант возможен, но очень глупый. Исходя из этого, в другой ЦОД необходимо будет перетянуть только состояние оперативной памяти, диски там уже будут, причем в максимально актуальном состоянии.
Опять же, live migration сотен виртуалок разом — нонсенс в любом случае. А если произошла (или вот-вот должна произойти) катастрофа, то тем более любой нормальный человек отбросит понты и просто поднимет виртуалки с реплицированного хранилища на новой площадке.
Но все-таки как сетевик я терпеть не могу L2, особенно когда он сильно спанится.
1) Делать простой транк между площадками — безумие. Авария на одном ЦОДе имеет шанс положить и соседа. Да и даже без аварий на транке будет гулять слишком много мусора. И нужны костыли, чтобы сервер на каждой из площадок выбирал правильного next hop'а. Так что надеюсь, так никто никогда не делает.
2) OTV к примеру гарантирует, что broadcast и unknown unicast трафик не будут бегать между ЦОДами, и скорее всего авария одной площадки не затронет другую («скорее всего» — полную гарантию даст только L3). Но он дорого стоит (Nexus 7k), и все равно трафик будет ходить абсолютно неоптимально.
Потому наиболее красивое решение — чтобы by design не было нужды перемещать машину с площадки на площадку с сохранением IP адреса. Пусть будут по две занятые общим делом машины в двух разных ЦОДах. В пределах ЦОДа можно делать балансировку средствами ACE. Между ЦОДами — GSS. Да можно хоть включить route injection — клиенты обращаются к VIP адресу ресурса, и этот VIP анонсируется как /32 маршрут тем балансировщиком, который является активным, а при смерти ЦОДа этот /32 маршрут через несколько секунд всплывет в другом месте. И уже неважно, какие у серверов адреса. И нет никакой нагрузки на сеть в момент переезда.
Все эти решения значительно лучше, чем «VLAN растянут на 2 ЦОДа».
Но в принципе, существует типичный конфликт непонимания между «server guys» и «network guys».
«И судя по тому, сколько усилий в этот направлении тратят производители сетевого оборудования и платформ виртуализации, функционал востребован заказчиками. „
Основные усилия тратятся производителями платформ виртуализации и направлены на промывание мозгов серверных админов. И часто бывает, что те загораются новой идеей и начинают давить на сетевиков, не понимая возникающих на уровне сети проблем. И тут сетевые вендоры присасываются к кормушке и выпускают костыли, убирающие часть проблем.
И мало кто акцентирует внимание на L3 технологиях, потому что тут в восторге будут сетевики, но не будет никаких killer-фич для server guys.
Но все-таки как сетевик я терпеть не могу L2, особенно когда он сильно спанится.
1) Делать простой транк между площадками — безумие. Авария на одном ЦОДе имеет шанс положить и соседа. Да и даже без аварий на транке будет гулять слишком много мусора. И нужны костыли, чтобы сервер на каждой из площадок выбирал правильного next hop'а. Так что надеюсь, так никто никогда не делает.
2) OTV к примеру гарантирует, что broadcast и unknown unicast трафик не будут бегать между ЦОДами, и скорее всего авария одной площадки не затронет другую («скорее всего» — полную гарантию даст только L3). Но он дорого стоит (Nexus 7k), и все равно трафик будет ходить абсолютно неоптимально.
Потому наиболее красивое решение — чтобы by design не было нужды перемещать машину с площадки на площадку с сохранением IP адреса. Пусть будут по две занятые общим делом машины в двух разных ЦОДах. В пределах ЦОДа можно делать балансировку средствами ACE. Между ЦОДами — GSS. Да можно хоть включить route injection — клиенты обращаются к VIP адресу ресурса, и этот VIP анонсируется как /32 маршрут тем балансировщиком, который является активным, а при смерти ЦОДа этот /32 маршрут через несколько секунд всплывет в другом месте. И уже неважно, какие у серверов адреса. И нет никакой нагрузки на сеть в момент переезда.
Все эти решения значительно лучше, чем «VLAN растянут на 2 ЦОДа».
Но в принципе, существует типичный конфликт непонимания между «server guys» и «network guys».
«И судя по тому, сколько усилий в этот направлении тратят производители сетевого оборудования и платформ виртуализации, функционал востребован заказчиками. „
Основные усилия тратятся производителями платформ виртуализации и направлены на промывание мозгов серверных админов. И часто бывает, что те загораются новой идеей и начинают давить на сетевиков, не понимая возникающих на уровне сети проблем. И тут сетевые вендоры присасываются к кормушке и выпускают костыли, убирающие часть проблем.
И мало кто акцентирует внимание на L3 технологиях, потому что тут в восторге будут сетевики, но не будет никаких killer-фич для server guys.
Местами соленое сравнивается с мягким. С точки зрения понимания на уровне ликбеза это допустимо, но солидные внедренцы всё-таки не допускают ошибок в такого рода статьях.
К сожалению, наша площадка еще не достроена и описания её на хабре нет. Однако часть инженеров IBM, мой опыт и здравый смысл цепляется за много моментов, которые вы сочли «легкими».
«Полная потеря ЦОДа будет отработана обычным HA-кластером в автоматическом режиме за несколько минут. Пожалуй, виртуализация разнесенных СХД позволяет обеспечить минимальное время восстановления для большинства приложений.»
Вот такого рода предложения обычно поясняют или приводят примеры. Кластеры, которые восстанавливаются после гибели ЦОДа, как показывает новейшая история, даже у гугла не отрабатывают корректно.
К сожалению, наша площадка еще не достроена и описания её на хабре нет. Однако часть инженеров IBM, мой опыт и здравый смысл цепляется за много моментов, которые вы сочли «легкими».
«Полная потеря ЦОДа будет отработана обычным HA-кластером в автоматическом режиме за несколько минут. Пожалуй, виртуализация разнесенных СХД позволяет обеспечить минимальное время восстановления для большинства приложений.»
Вот такого рода предложения обычно поясняют или приводят примеры. Кластеры, которые восстанавливаются после гибели ЦОДа, как показывает новейшая история, даже у гугла не отрабатывают корректно.
Это действительно обзорный пост. Посмотрев на обратную связь, я планировал более подробно написать о некоторых из упомянутых решений подробно, в контексте референсных архитектур. Что касается конкретного кейса с HA-кластерами, описанный мной сценарий возможен, в случае того же VPLEX. Условием корректной отработки полного отказа ЦОДа со стороны VPLEX (т.е. подсистемы хранения данных, с точки зрения сервера) является наличие специальной виртуальной машины-наблюдателя, где-то в третьей локации. Она видит по IP контроллеры VPLEX в обоих ЦОДах, и позволяет отличить ситуацию отказа коммуникаций между двумя ЦОДами (когда внутри площадки все живо), от отказа ЦОДа целиком. Если контроллер не видит своего собрата, но видит наблюдателя и со стороны наблюдателя картина та же — все тома забираются в выживший ЦОД. В случае SVC возможен такой же наблюдатель, но он должен видеть все узлы по оптике. Другой вопрос, что в жизни могут быть нарушены и коммуникации с третьей площадкой-наблюдателем. Всегда возможна ситуация, когда самый продуманный кластер не отработает. Надо просто выбрать наилучшую технологию из имеющихся на рынке.
При всем при этом, ценность любого геокластера в «ручном» режиме работы не намного меньше, чем в автоматическом. Отказы ЦОДов целиком случаются редко, главное, чтобы когда человек разобрался, что делать и принял решение — его выполнение прошло максимально быстро. Оснобенно, когда надо переводить на резервную площадку десятки систем. Десятки минут простоя при этом абсолютно нормальны, главное, чтобы они не превратились в многие часы и дни.
При всем при этом, ценность любого геокластера в «ручном» режиме работы не намного меньше, чем в автоматическом. Отказы ЦОДов целиком случаются редко, главное, чтобы когда человек разобрался, что делать и принял решение — его выполнение прошло максимально быстро. Оснобенно, когда надо переводить на резервную площадку десятки систем. Десятки минут простоя при этом абсолютно нормальны, главное, чтобы они не превратились в многие часы и дни.
В статье затронута тема обеспечения софтверной устойчивости. Я работал в телеком компаниях, таких как Corbina и Yota. Я начинал спать спокойно, когда добивался от руководства территориального разнесения маршрутов соединения основных узлов связи. Результатом становилось то, что если перебьют кабель в одном месте, то все работало, и ночью не приходилось поднимать пол фирмы для решения проблемы, а можно было дождаться утра и все восстановить в штатном режиме.
Но к моему величайшему сожалению, нужные сметы на строительство подписывались, только после 2-3 крупных аварий, которые становились детонатором ситуации.
Но к моему величайшему сожалению, нужные сметы на строительство подписывались, только после 2-3 крупных аварий, которые становились детонатором ситуации.
Совершенно справедливый комментарий, спасибо. В этом посте я не затрагивал очень важную тему построения отказоустойчивых сетей LAN, WAN, SAN между ЦОДами. Постараюсь написать об этом один из следующих постов.
Ситуация с авариями как детонаторами перемен мне знакома. Если руководство воспринимает только это — важно предлагать варианты решения по горячим следам, не ждать, пока время вылечит. Непосредственно с Корбиной и Скартелом/Yota не работал, кстати.
Очень важен общий уровень риск-менеджмента в компании и взаимодействия профильного подразделения с ИТ. Во некоторых наших бурно растущих бизнесах процессы отстают от масштаба деятельности. Я считаю, что донести до риск-менеджеров и руководства в целом мысль о важности инвестиций в непрерывность бизнеса можно. Главное, как следует подготовиться — собрать примеры последствий отказов у ваших конкурентов и в вашей собственной инфраструктуре, попытаться грубо оценить стоимость простоя. Взглянуть на ситуацию со стороны бизнеса, одним словом.
Ситуация с авариями как детонаторами перемен мне знакома. Если руководство воспринимает только это — важно предлагать варианты решения по горячим следам, не ждать, пока время вылечит. Непосредственно с Корбиной и Скартелом/Yota не работал, кстати.
Очень важен общий уровень риск-менеджмента в компании и взаимодействия профильного подразделения с ИТ. Во некоторых наших бурно растущих бизнесах процессы отстают от масштаба деятельности. Я считаю, что донести до риск-менеджеров и руководства в целом мысль о важности инвестиций в непрерывность бизнеса можно. Главное, как следует подготовиться — собрать примеры последствий отказов у ваших конкурентов и в вашей собственной инфраструктуре, попытаться грубо оценить стоимость простоя. Взглянуть на ситуацию со стороны бизнеса, одним словом.
Sign up to leave a comment.
Катастрофоустойчивые IT-системы: как внедрить в своей компании