NetApp и MS Hyper-V Best Practices: новый перевод на сайте Netwell
На сайте компании-дистрибутора Netwell, на страничке переводов официальных Best Practices, выложен наш новый большой перевод:
Наилучшие методы использования систем хранения NetApp для решений виртуализации Microsoft Hyper-V и Hyper-V R2
Это почти 100-страничное руководство по наилучшим способам настройки и использования систем хранения NetApp FAS и системы серверной вируализации Microsoft Hyper-V/R2.
Кстати говоря, многие главы будут полезны и “в отрыве” от NetApp, тем людям, кто хочет побольше узнать о том, как работает Hyper-V сам по себе, и могут быть применимы к использованию с любыми системами хранения.
Краткая его аннотация выглядит так:
Этот документ содержит руководство и описание наилучших методов для построения интегрированной архитектуры и внедрения Microsoft Hyper-V с использованием систем хранения NetApp. Технологии NetApp, рассматриваемые в этом руководстве важны для создания эффективного с точки зрения затрат, производительности, гибкости и дружественности к окружающей среде интегрированного решения хранения данных виртуальной серверной инфраструктуры.
Будем считать, что публикация приурочена к Microsoft Virtualization Summit в Москве. :)
Вау! Супер! Отдам работникам для заучивания наизусть! :)
Переводили, я так понимаю, технические работники? Ради Бога, не обижайтесь, но если проф. переводчики, то я б заставил их переписать - ну разве это по-русски?
“Microsoft также не поддерживает использование NIC teaming для сетей, использующихся для передач данных iSCSI. Поэтому вы можете не использовать логический сетевой интерфейс для сети iSCSI, когда работаете через Microsoft iSCSI Software Initiator для того, чтобы подключить LUN к хост‐OS Hyper‐V (parent partition). Кроме этого, когда логический NIC подключается к виртуальному коммутатору, виртуальные машины, подсоединенные к этому виртуальному коммутатору, не должны иметь включенного Microsoft iSCSI Software Initiator на этом виртуальном NIC.”
??ли специально была поставлена задача дословного перевода, чтоб ничего не переврали?
Спасибо!
Переводил я сам, так что все претензии сюда :)
Да, я конечно старался “русифицировать” текст, но не всегда это удавалось, потому что был страх “литературизовать” в ущерб точности.
Опять же, есть там какие-то моменты, когда я, не будучи специалистом по технологиям виртуализации MS, “плавал”, судорожно пытаясь нащупать дно среди потока терминов :)
Так что если найдете плюхи - давайте их сюда, поправлю.
??ногда, конечно, выползали из меня вот такие языковые кадавры, недосмотрел, да, что уж оправдываться ;)
Если есть желание порецензировать, то могу дать вордовский оригинал.
Ну что я могу отрецензировать? Переводить заново я не буду, потому что отлично знаю, какой это огромный труд. Может профессиональные переводчики и могут печь текст, как пирожки, мне же на литературный перевод страницы текста забитого терминами требуется целый вечер - пробовал.
По самому тексту, я б подискутировал с авторами. Вот прочёл раздел 2.1 и категорически несогласен. Люди отталкиваются от устаревших на 10 лет непрофессиональных с точки зрения сетевика представлений MS(ах, самой MS!), которые ещё больше усугубляет желание отказаться от ответственности. MS говорит: мы не поддерживаем link aggregation (teaming), поэтому рекомендуем всем обвязаться кроссовыми патч-кордами и спрыгнуть с моста. Сами же авторы пишут, что это бред, просто не дело M$ заниматься LA, этим занимаются Broadcom и intel. А вот дальше поразительные выводы делаются - пусть мы наплевали на глупые рекомендации софтверников, но мы будем придерживаться рекомендаций софтверников во что бы то ни стало!
?? апофеоз - несчастному серверу виртуализации нужно 50-60 гигабит сетевого коннективити! 8-[__]
Хотя страницей раньше пытались обосновать эти 5-6 проводов следующими соображениями:
1. не хватит пропускной,
2. live миграция и иже с ней перебьёт канал критичным данным,
3. повышение надежности.
Первый пункт сходу уходит если мы говорим о переходе на 10G - 20 гигабит от сдвоенного 10G всяко быстрей 5-6 гигабиток.
Второй пункт говорит только о том, что писавший никогда с серьёзным сетевым железом не сталкивался, что такое QoS во всём его многообразии не знает, или пишет практики для SOHO с мыльницами-сурекомами-длинками. Более того, даже без QoS дай Бог даже самой зверской передачей информации 10 гигабит, не то что 20 забить - кто эту информацию с такой скоростью обрабатывать будет? А если заткнется процессор/память/шина, то с одной сетевухи заткнётся или с шести - легче не станет.
??деология же третьего тезиса написна лет 10-20 назад и с тех пор не переосмысливалась. А между тем сети строятся теперь совсем по-другому. Авторам по привычке кажется, что кинув, пардон, “соплю” между двумя серверами они повысят надёжность, избавившись от необходимости использовать эти Страшные-Сложные-Ненадёжные-Дорогие-Коммутаторы(!). На самом деле они создадут ПЯТЬ single points of failure: сетевая карта, разъём, провод, разъём, сетевая карта.
Правильной best practice будет совершенно другая схема: (для варианта с 2 нодами) два сервера со сдвоенными сетевыми картами 1G или 10G (для параноиков - две одинарных карты). Два коммутатора в стеке или соответственно сконфигурированный отказоустойчивый шассийный коммутатор. Подключение LA “крест-накрест”. Внутри - VLAN-ы. Qos. Система не имеет единых точек сбоя, и при грамотном подходе к распределению пропускной, не будет создавать помех критичной информации. Пропускная способность канала доступна всем приложениям по требованию, а не как в их best practice, где одни задачи могут задыхаться, а другие будут грузить канал в среднем на 0,0001% (управление, heartbeat).
Ну нет, конечно. Перефразируя известную поговорку про раввинов, “три собравшихся вместе сисадмина по поводу любого IT-вопроса будут иметь как минимум 4 мнения” :) Поэтому речь идет не о правильности изложенных мнений. Оставим их все на совести авторов.
Как и не о литературной правке, иначе мне придется делиться гонораром (а я его уже прогулял%)
Но если заметите что-то, на что указать вам не будет стоить ничего ;) или увидите какую-то откровенную корявость в переводе - вы конечно можете это мне указать, если таких правок наберется, и они будут существенны, мы перевыложим текст.
В Опере (браузер такой) что 9-й, что 10-й версий эта страница смотрится весьма готично, рекомендую :)
Опера это там где арии поют, я знаю, ага.