none
Дизайн отказоустойчивого решения Hyper-v на 2 площадках RRS feed

  • Общие обсуждения

  • Дано:

    2 площадки, на каждой по N серверов Hyper-v, и по 1 системе хранения SAN.

    Между площадками fiber chanel линки, фактически это одна сеть SAN.

    Как сделать решение, которое позволило бы при отключении одной из площадок, в кратчайшие сроки обеспечить работу виртуальных машин с данной выключенной площадки на второй площадке?

    Самое первое что пришло на ум, это новая функция Windows server 2012 Hyper-V Replica, но она может потерять данные до 5 минут, не хранит оперативную память, холодный запуск виртуалок.

    Коллеги, кто знает более крутой способ для данного кейса?  

    7 марта 2013 г. 12:58

Все ответы

  • >фактически это одна сеть SAN

    Репликация SAN и один кластер Hyper-V на обе площадки. Круче и дороже мало что можно придумать.


    http://OpsMgr.ru/

    8 марта 2013 г. 2:16
    Отвечающий
  • Дороже можно!

    Решения HP железные вроде есть без холодного старта.

    8 марта 2013 г. 16:27
  • Круче и дороже мало что можно придумать.


    http://OpsMgr.ru/


    Можно. На каждой площадке поставить еще и по ftServer от Stratus.
    11 марта 2013 г. 4:53
    Модератор
  • Denis Dyagilev

    можно простым языком о ftServer от Stratus? а то мы сейчас ищем кажется нечно подобное!

    11 марта 2013 г. 6:12
  • Это реализация Fault-Tolerant для Hyper-V посредством дублирования практически всех

    аппаратных компонентов - ОЗУ, дисков, сетевых интерфейсов с непрерывной репликацией данных между ними. Грубо говоря - это два сервера в одном корпусе.

    11 марта 2013 г. 6:41
    Модератор
  • >фактически это одна сеть SAN

    Репликация SAN и один кластер Hyper-V на обе площадки. Круче и дороже мало что можно придумать.


    http://OpsMgr.ru/

    Алексей, а репликация SAN должна выполняться средствами системы хранения или же она делается благодаря функционалу Windows 2012?

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

    Расскажите подробнее о решении которое Вы предлагаете или дайте, пожалуйста, ссылку.

    11 марта 2013 г. 13:18
  • Репликация происходит на уровне СХД, и для кластера гипервизоров хранилища на обеих площадках видятся как одно, переключение, по идее, происходит прозрачно.
    11 марта 2013 г. 13:38
    Модератор
  • Денис, для этого нужна очень дорогая лиценция и хайенд хранилки. Пока хотелось бы рассмотреть варианты, которые можно осуществить средствами ОС.

    И хотелось бы меньше использовать возможности СХД. Канал между площадками очень быстрый фактически одна площадка, только СХДшки 2. Есть еще идеи?

    11 марта 2013 г. 13:50
  •  . . . нужна очень дорогая лиценция и хайенд хранилки.  . . .

    И хотелось бы меньше использовать возможности СХД. Канал между площадками очень быстрый фактически одна площадка, только СХДшки 2. Есть еще идеи?

    ~

    ~

    Alexey Zhuravlev - G14 :


    >фактически это одна сеть SAN

    Репликация SAN и один кластер Hyper-V на обе площадки. Круче . . .  мало что можно придумать.


    ~

    "Репликация SAN" :

    StarWind HA   -- iSCSI  , "active-active-active" начиная с v6.0 , "active-active"

    ~

    Только лучше 3 узла на 3-x  точках

    ~

    На нем -- "кластер Hyper-V" 

    ~



     . . . новая функция Windows server 2012 Hyper-V Replica, но она может потерять данные до 5 минут, не хранит оперативную память, холодный запуск виртуалок.

    ~

    Starwind HA данные не потеряет, но остальное аналогично: RAM не зазеркалит, VM будут как после холодного рестарта

    ~

    . . . при отключении одной из площадок, . . .

    ~

     Хотя: если до отключения есть хотя бы 2-3 часа/полчаса, например "известно что горючее в дизеле кончается, а цистерны не будет" , то можно попробовать мигрировать VM средствами Hyper-V кластера

    ~

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

    ~

    "active-passive" ?

    на LUN-е CSV Hyper-V кластера?

    ~

    ~

     См. так же:

    http://social.technet.microsoft.com/Forums/ru-RU/virtualizationru/thread/ecffe8e2-3be9-473c-bbec-4f65701c52b4/

    ==

    Если ВМ содержит:

    -- Exchange

    -- MS SQL

    -- Oracle

    то у них есть собственные разновидности кластеризации т.е. создаем 2-а Hyper-V кластера

    и в каждом по половине DataBase-кластера плюс по половине TS/OWA/DB-clients серверов

    > отключаю сетевые интерфейсы

    Ставим 2x LanCARD + дублирование switches

    P.S.

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

      Еще более правильно переводить H-V узел в "maintence mode" средствами SC VMM

    ==

    ~

    ~

    Denis Dyagilev :


    ftServer от Stratus -- Это реализация Fault-Tolerant для Hyper-V посредством дублирования практически всех

    аппаратных компонентов - ОЗУ, дисков, сетевых интерфейсов с непрерывной репликацией данных между ними. Грубо говоря - это два сервера в одном корпусе.

    ~

    Или так . . .

    ~



    P.S.

    http://habrahabr.ru/company/croc/blog/169333/

    ==

    14 февраля в 11:13

    Системы хранения данных: как медленно, но верно они отвязываются от железа

     . . .

    К примеру — скорость света становится реальным физическим барьером, который не даёт заказчику поставить второй ЦОД дальше 40-50, а то и меньше, километров от первого.

     . . .

    Про синхронизацию


    Есть три конфигурации – Local (1 ЦОД), Metro (синхронная репликация) и Geo (2 асинхронных ЦОД). Разновидность синхронной репликации с x-подключением – Campus. Синхронная репликация наиболее востребована (это 99% внедрений в России). Здесь в дело вступает бессердечная скорость света, которая устанавливает максимальное расстояние между ЦОДами — должно хватить 5 миллисекунд на прохождение сигнала. Можно настраивать и с 10 миллисекундами, но чем ближе ЦОДы — тем лучше. Обычно это 30-40 километров максимум.

     . . .

    ==


    12 марта 2013 г. 11:01