none
Кластер, MPIO и автоматический failover. RRS feed

  • Вопрос

  • Приветствую!

    Планируем  строить  отказоустойчивый двухузловой  кластер с помощью  "недорогих" 10гб  стораджей.

    Предполагается, что  между стораджами будет синхронная репликация. Сразу скажу, что  нам ранее с репликацией  и  mpio  работать не приходилось,  поэтому можем ошибаться в своих  представлениях.

    Вот, предположим, что   у нас    оба узла подклчюены к основной сторе1,  которая нам представляет десяток  ЛУНов.  Оба же узла подключены к сторе2, но она у них   резервная на случай выхода из строя первой.

    Вопросы:

    1.Правильно ли я понимаю, что "репликация" означает, что на сторе2  у нас будет ровно тот же десяток ЛУНов с теми же данными на них?

    2.Правильно я понимаю,  что для автоматического переподключения серверов к сторе2 нам нужно настроить либо MPIO, либо NIC teaming таким образом, чтобы активный путь указывал на список лунов на активной сторе1,  а фейловер путь указывал на список лунов на пассивной сторе?

    Спасибо.

     

    12 февраля 2014 г. 15:08

Ответы

  • Приветствую!

    Планируем  строить  отказоустойчивый двухузловой  кластер с помощью  "недорогих" 10гб  стораджей.

    Предполагается, что  между стораджами будет синхронная репликация. Сразу скажу, что  нам ранее с репликацией  и  mpio  работать не приходилось,  поэтому можем ошибаться в своих  представлениях.

    Вот, предположим, что   у нас    оба узла подклчюены к основной сторе1,  которая нам представляет десяток  ЛУНов.  Оба же узла подключены к сторе2, но она у них   резервная на случай выхода из строя первой.

    Вопросы:

    1.Правильно ли я понимаю, что "репликация" означает, что на сторе2  у нас будет ровно тот же десяток ЛУНов с теми же данными на них?

    2.Правильно я понимаю,  что для автоматического переподключения серверов к сторе2 нам нужно настроить либо MPIO, либо NIC teaming таким образом, чтобы активный путь указывал на список лунов на активной сторе1,  а фейловер путь указывал на список лунов на пассивной сторе?

    Спасибо.

     

    Здравствуйте! 

    Буду краток:

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

    2.NIC тиминг и iSCSI кровные враги по многим причинам, в основном изза произодительности, так что только MPIO. Но сам принцип вы поняли абсолютно верно - подключаетесь к обоим копиям данных по iscsi и если одна "умрет", то клиент будет работать со второй автоматически, пока погибшая часть не воскреснет. 

    Хочу уделить Ваше внимание факту, что стоящими являются решения, которые предоставляют хранилище с active-active высокой доступностью, а не active-passive, так как вторые имеют значительные проседание производительности за счет особенностей архитектуры, да и failover у них тоже больше, а соответственно и простой в случае падения. В принципе как должен выглядеть хороший SAN описано тут (по крайне мерее основные моменты):

    http://ru.starwindsoftware.com/native-san-for-hyper-v-benefits

    Скажите пожалуйста, а Вы СХД уже выбрали или еще нет?  

     


    13 февраля 2014 г. 17:11
  • В случае репликации средствами вендора хранилищ оба СХД представляются кластеру как единое целом. Грубо говоря, узлы и кластер не знают, что презентованный том на уровне "стораджей" является распределенной структурой. Если у Вас под репликацией подразумевается не такая схема, то Ваш сценарий неработоспособен.

    Исходя из вышесказанного:

    1) Да. Но повторюсь, что кластер должен видеть не Стор1 и Стор2, а некий Стор0, который образован средствами системы хранения;

    2) MPIO и NIC Teaming вместе использовать нельзя. В Вашем случае нужно использовать MPIO, настроенный на подключение Стор0.

    12 февраля 2014 г. 18:16
    Модератор

Все ответы

  • В случае репликации средствами вендора хранилищ оба СХД представляются кластеру как единое целом. Грубо говоря, узлы и кластер не знают, что презентованный том на уровне "стораджей" является распределенной структурой. Если у Вас под репликацией подразумевается не такая схема, то Ваш сценарий неработоспособен.

    Исходя из вышесказанного:

    1) Да. Но повторюсь, что кластер должен видеть не Стор1 и Стор2, а некий Стор0, который образован средствами системы хранения;

    2) MPIO и NIC Teaming вместе использовать нельзя. В Вашем случае нужно использовать MPIO, настроенный на подключение Стор0.

    12 февраля 2014 г. 18:16
    Модератор
  • Приветствую!

    Планируем  строить  отказоустойчивый двухузловой  кластер с помощью  "недорогих" 10гб  стораджей.

    Предполагается, что  между стораджами будет синхронная репликация. Сразу скажу, что  нам ранее с репликацией  и  mpio  работать не приходилось,  поэтому можем ошибаться в своих  представлениях.

    Вот, предположим, что   у нас    оба узла подклчюены к основной сторе1,  которая нам представляет десяток  ЛУНов.  Оба же узла подключены к сторе2, но она у них   резервная на случай выхода из строя первой.

    Вопросы:

    1.Правильно ли я понимаю, что "репликация" означает, что на сторе2  у нас будет ровно тот же десяток ЛУНов с теми же данными на них?

    2.Правильно я понимаю,  что для автоматического переподключения серверов к сторе2 нам нужно настроить либо MPIO, либо NIC teaming таким образом, чтобы активный путь указывал на список лунов на активной сторе1,  а фейловер путь указывал на список лунов на пассивной сторе?

    Спасибо.

     

    Здравствуйте! 

    Буду краток:

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

    2.NIC тиминг и iSCSI кровные враги по многим причинам, в основном изза произодительности, так что только MPIO. Но сам принцип вы поняли абсолютно верно - подключаетесь к обоим копиям данных по iscsi и если одна "умрет", то клиент будет работать со второй автоматически, пока погибшая часть не воскреснет. 

    Хочу уделить Ваше внимание факту, что стоящими являются решения, которые предоставляют хранилище с active-active высокой доступностью, а не active-passive, так как вторые имеют значительные проседание производительности за счет особенностей архитектуры, да и failover у них тоже больше, а соответственно и простой в случае падения. В принципе как должен выглядеть хороший SAN описано тут (по крайне мерее основные моменты):

    http://ru.starwindsoftware.com/native-san-for-hyper-v-benefits

    Скажите пожалуйста, а Вы СХД уже выбрали или еще нет?  

     


    13 февраля 2014 г. 17:11