Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 13
Шикарно, спасибо!
В случае протокола NFS необходимо иметь минимум один Data LIF с установленным IP адресом на каждой ноде СХД, который подключён в ту же подсеть сеть, что и соответствующий VMkernel на ESXi хосте.
Это ограничение VVOL? Ведь с обычными датасторами LIF ездит между нодами.
Может быть дело в производительности? В таком случае трафик будет бегать только в пределах одной ноды, а вторая будет простаивать.
А толку гнать трафик через вторую ноду, когда агрегатом один? Вопрос в необходимости изменить топологию по сравнению с ESXi 5.5, где не было мультипасинга и использовался один адрес с LAG для фейловера.
Если агрегат один, то действительно толку нет. В вашем случае, один дополнительный, IP хлеба не просит. Дело в том, что основная масса заказчиков нетапа это системы с более чем одним агрегатом у которых используется Active/Active конфигурация.
Таким образом архитектура устроена так, чтобы предусмотреть возможность масштабирования на две и более ноды.
Таким образом архитектура устроена так, чтобы предусмотреть возможность масштабирования на две и более ноды.
В вашем случае, один дополнительный, IP хлеба не просит.
Спасибо за пояснение, а то мне вспомнилась чудовищная схема подключения из TR-3749, где предлагали создавать по VMKernel на каждый порт контроллера.
Согласен, та схема была достаточно тяжёлая. Я кстати писал про такую схему когда-то давно. На самом деле та схема, это костыль к Ethernet, потому, что он плохо балансирует по линкам и у него нет встроенного мультипасинга для отказоустойчивости.
К сожалению VVOL пока что так и не научился работать с pNFS, в котором по-своему решена эта проблема. Надеюсь что VMware работает в этом направлении.
К сожалению VVOL пока что так и не научился работать с pNFS, в котором по-своему решена эта проблема. Надеюсь что VMware работает в этом направлении.
Как уже было сказано ранее, PE это прослойка виртуализации, промежуточное звено, через которое происходит обращение от хоста к VVOL. Из чего вытекает, что если пропадёт PE, то пропадёт доступ ко всем VVOL которые он мапил. Но так как вы уже сказали, IP адрес ездит по портам и нодам, то это не проблема.
Как вы можете знать в случае переезда только лишь IP адреса на другую ноду, доступ к данным будет осуществляться не напрямую, а через не оптимальный путь — пока IP будет на одной ноде, а данные на другой то доступ к ним будет осуществляться через кластерную сеть.
Такая ситуация может просходить по двум причинам:
Итак не оптимальный путь к данным в случае переезда IP это так или иначе временная мера — защитный механизм.
А что если вы имеете несколько нод в кластере, каждая из которых имеет ресурсы хранения, вы же хотите чтобы доступ к ним всегда осуществлялся напрямую по оптимальному пути? Всё очень просто для этого нужно создать IP адреса на каждой ноде.
Как вы можете знать в случае переезда только лишь IP адреса на другую ноду, доступ к данным будет осуществляться не напрямую, а через не оптимальный путь — пока IP будет на одной ноде, а данные на другой то доступ к ним будет осуществляться через кластерную сеть.
Такая ситуация может просходить по двум причинам:
- Вы прозрачно мигрируете ваши данные с одной ноды на другую: в таком случае, будет момент времени когда ваш IP по которому вы получяете доступ к данным на одной ноде, а ваши данные на другой. Это временная ситуация которая в результате завершается тем, что IP и данные переезжают на одну ноду и доступ к ним снова происходит «напрямую» без кластерной сети по оптимальному пути. А на LIF интерфейсе меняется Home порт — тот который будет на новой ноде.
- Когда нода или сетевой порт или сетевой линк умерли. Тогда задействуется механизм временного переезда IP адреса на другой порт. Здесь ключевое слово ВРЕМЕННО. Потому что когда всё восстановиться он поедет обратно на свой родной Home порт.
Итак не оптимальный путь к данным в случае переезда IP это так или иначе временная мера — защитный механизм.
А что если вы имеете несколько нод в кластере, каждая из которых имеет ресурсы хранения, вы же хотите чтобы доступ к ним всегда осуществлялся напрямую по оптимальному пути? Всё очень просто для этого нужно создать IP адреса на каждой ноде.
Ограничения и технические требования описаны в TR документе о vVOL на стр 10.
Пара новостей по теме: поддержка vSphere 6.5 появится в VSC 6.2.1P1, которая выйдет 23 февраля.
А в июне должны выпустить VSC 7.0, где наконец откажутся от винды и она будет поставляться сразу в OVF.
А в июне должны выпустить VSC 7.0, где наконец откажутся от винды и она будет поставляться сразу в OVF.
Спасибо за новость! Кстати ориентировочно к этому времени выйдет ONTAP 9.2.
Полагаю, оба этих события ONTAP 9.2 & VSC 7.0 будут приурочены VASA API v3.0.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
NetApp ONTAP & VMware vVOL