Комментарии к записи: NetApp и MS Hyper-V Best Practices: новый перевод на сайте Netwell

Автор: romx

romx — Wed, 07 Apr 2010 07:19:43 +0000

Опера это там где арии поют, я знаю, ага.

Автор: nimdamsk

nimdamsk — Wed, 07 Apr 2010 07:14:04 +0000

В Опере (браузер такой) что 9-й, что 10-й версий эта страница смотрится весьма готично, рекомендую :)

Автор: romx

romx — Tue, 06 Apr 2010 11:17:35 +0000

Ну нет, конечно. Перефразируя известную поговорку про раввинов, “три собравшихся вместе сисадмина по поводу любого IT-вопроса будут иметь как минимум 4 мнения” :) Поэтому речь идет не о правильности изложенных мнений. Оставим их все на совести авторов.
Как и не о литературной правке, иначе мне придется делиться гонораром (а я его уже прогулял%)
Но если заметите что-то, на что указать вам не будет стоить ничего ;) или увидите какую-то откровенную корявость в переводе - вы конечно можете это мне указать, если таких правок наберется, и они будут существенны, мы перевыложим текст.

Автор: Korj

Korj — Tue, 06 Apr 2010 10:52:59 +0000

Ну что я могу отрецензировать? Переводить заново я не буду, потому что отлично знаю, какой это огромный труд. Может профессиональные переводчики и могут печь текст, как пирожки, мне же на литературный перевод страницы текста забитого терминами требуется целый вечер - пробовал.
По самому тексту, я б подискутировал с авторами. Вот прочёл раздел 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).

Автор: romx

romx — Tue, 06 Apr 2010 10:05:32 +0000

Переводил я сам, так что все претензии сюда :)
Да, я конечно старался “русифицировать” текст, но не всегда это удавалось, потому что был страх “литературизовать” в ущерб точности.
Опять же, есть там какие-то моменты, когда я, не будучи специалистом по технологиям виртуализации MS, “плавал”, судорожно пытаясь нащупать дно среди потока терминов :)
Так что если найдете плюхи - давайте их сюда, поправлю.
??ногда, конечно, выползали из меня вот такие языковые кадавры, недосмотрел, да, что уж оправдываться ;)

Если есть желание порецензировать, то могу дать вордовский оригинал.

Автор: Korj

Korj — Tue, 06 Apr 2010 09:50:04 +0000

Вау! Супер! Отдам работникам для заучивания наизусть! :)
Переводили, я так понимаю, технические работники? Ради Бога, не обижайтесь, но если проф. переводчики, то я б заставил их переписать - ну разве это по-русски?
“Microsoft также не поддерживает использование NIC teaming для сетей, использующихся для передач данных iSCSI. Поэтому вы можете не использовать логический сетевой интерфейс для сети iSCSI, когда работаете через Microsoft iSCSI Software Initiator для того, чтобы подключить LUN к хост‐OS Hyper‐V (parent partition). Кроме этого, когда логический NIC подключается к виртуальному коммутатору, виртуальные машины, подсоединенные к этому виртуальному коммутатору, не должны иметь включенного Microsoft iSCSI Software Initiator на этом виртуальном NIC.”
??ли специально была поставлена задача дословного перевода, чтоб ничего не переврали?

Спасибо!