headermask image

Загрузка винды по сети

Собственно, проблема загрузки виндов по сети делится на две. Первое, это драйвер, который даст виндам доступ к сетевому устройству: как минимум, он должен быть boot-capable, и соответственно должен уметь работать без поддержки user-space компонент, SMSS и так далее. Второе, это начальный загрузчик, который загружаемый комп получит по TFTP и которому предстоит эмулить доступ к тому же сетевому устройству по старому доброму int 13 – для NTLDR – имея в наличии только UNDI. Ключевое слово здесь – “к тому же самому”, т.к. NTLDR грузит registry, и это должно быть именно то же самое registry, с которым потом будут работать винды – если не рассматривать вариант, когда сетевое хранилище для клиента read-only, и клиент грузится с EWF, в этом случае для начальной загрузки может быть использован другой протокол и другое хранилище. Но это не наш случай.

Способов доступа к сетевому блочному устройству в виндах в общем-то есть не так много.

iSCSI

SCSI – довольно монстроподобный протокол. Фактически это инкапсуляция SCSI в TCP, не более, с некоторыми наворотами на тему детекта, идентификации и т.п. Несмотря на накладные расходы из-за TCP, производительность впечатляет – 80 метров в секунду по гигабитке в полностью софтверном режиме и даже без jumbo frames, это довольно круто. Софтверных серверов iSCSI есть, не в ассортименте, но как минимум два есть: WinTarget и StarWind. Оба коммерческие, оба есть ломаные. StarWind не работает с линуксовым open-iscsi инициатором, поэтому отменяется. WinTarget работает прекрасно и с open-iscsi, и с виндовым официальным Microsoft iSCSI Initiator, и со StarWind’овским, называющимся StarPort. Вообще сугубо для доступа к сетевому диску – это абсолютно наилучшее решение, если отвлечься от стоимости лицензии. Но в домашних условиях пока еще можно отвлечься, так что мы не будем париться.

(iSCSI Initiator – это просто “клиент” в терминологии iSCSI, собственно как и в обычном SCSI – устройство, отсылающее запрос по шине, называется initiator, а отвечающее – target).

Но вот с загрузкой по iSCSI все не очень хорошо. Microsoft iSCSI Initiator – формально boot-capable, но только в версии для 2003 Server. Даже если предположить, что это можно обойти, то вторая проблема – начальный загрузчик – остается в полный рост, никакого официального решения не предлагается. Вернее, Microsoft предлагает воткнуть аппаратный iSCSI HBA, но – я даже не говорю, сколько они стоят, проблема в том, что здесь его еще и не купишь.

В Etherboot, который загрузчик всего и вся, загрузка по iSCSI поддерживалась, но перестала из-за legal issues с MS. Они реализовали начальную загрузку и доступ по int13, а затем через какой-то интерфейс осуществляли handoff микрософтовскому инициатору, что их и сгубило – MS решила, что этот интерфейс дюже секретный. В любом случае работало это, судя по всему, опять же только в 2003 Server.

Вторая альтернатива – это netBoot/i, в котором загрузчик сочетается со своим инициатором, соответственно это работает в любых виндах, и у них вроде никаких legal issues нет. Но – corporate customers only, и ломаного или хотя бы просто краденого, несмотря на усиленные поиски, найти мне не удалось. Более того, на evaluation request (прикинуться corporate customer’ом всегда можно) они не отвечают, на просто мыло тоже. Сколько стоит лицензия – не очень понятно, на сайте не сказано ничего, гугл говорит – $95, но возникает опять же вопрос, как ее купить. Так что остается ждать, пока кто-нибудь украдет.

Написать самому малореально, даже взяв Etherboot за основу. iSCSI – чертовски тяжелый протокол в реализации, унаследовавший весь геморрой обычного SCSI и добавивший нового. Линуксоиды до сих пор не справились с написанием даже клиента (open-iscsi практически неработоспособен и годится только для загрузки роутеров, и то с трудом), так что увы.

ATA-over-Ethernet

Компания CoRAID решила, что вся эта айсказзевая жесть – это в большинстве случае перебор, и решила гонять по сети старый добрый IDE, он же ATA. Причем гонять прямо в raw ethernet, никаких там TCP, IP и прочих лукавых мудрствований. Вообще они все упростили донельзя, с прицелом на дешевые аппаратные реализации, но нас интересуют сотфверные.

Софтверный сервер AoE есть, называется vblade. К сожалению, он сугубо линуксовый, но судя по описаниям и отзывам, все это вполне в production stage, так что – если считать, что линуксовый комп есть – с этим, наверно, жить можно. Виндовый клиент AoE входит в StarPort, который есть ломаный, да и лицензия на него стоит недорого. Но он, к сожалению, ни разу не boot-capablе, и это единственный вариант.

Начальный загрузчик по AoE в Etherboot находится в development stage, но это не проблема – главное, что он в принципе есть, а простота реализации такова, что накосячить очень сложно. Но – факт в том, что готового работающего AoE-решения на текущий момент нет. Его, правда, можно за разумное время написать самому и это будет нормально работать, так что над этим стоит подумать. Производительность должна быть по крайней мере сопоставима с iSCSI, особенно если поддержать tagged queueing, а накладные расходы на инкапсуляцию и, как следствие, нагрузка на проц, в разы меньше.

У линуксоидов, кстати, с AoE хорошо – там и клиент есть, и тоже вполне себе production, судя по всему. Но грузить линукс по сети вообще просто кучей способов по любым протоколам, потому как монолитное ядро да initrd – фигли там не грузить, это не винды. В примитивных решениях все-таки есть своя прелесть.

Проприетарные варианты

Компания Neoware делает приблуду, гордо называемую Neoware Image Manager. Там в одном флаконе начальный загрузчик, драйвер сетевого диска и сервер. Она использует свой протокол поверх UDP, а сервер есть виндовый и линуксовый, оба полностью user-space. В общем, тоже довольно просто.

Купить ее тоже нельзя, corporate customers, 50+ licenses only, как обычно. Но в ed2k она есть – недокачанный, правда, архив, но слава InstallShield, который кладет setup.dll в конец архива. Без setup.dll пережить можно, благо, инсталлер там ничего особо и не делает. Она там не ломаная и готового патча я не нашел, так что пришлось отучить от желания читать файл с лицензиями самому – благо, защита там примитивная, как и вообще вся прога.

Работает она следующим образом. На клиенте запускается image builder, который ставит прямо на живой машине дрова этого сетевого диска, затем чохом, не мудрствуя лукаво, делает образ живого винта, и вперед, с него можно грузиться. К сожалению, все это конкретно глюкен зи махт. Во-первых, она не любит больше одной сетевухи. На чистых виндах под vmware у ней почему-то не получается поменять start type у драйвера сетевухи, приходится самому, пока она тупит, менять ей руками, а то будет inaccessible boot device. На живой машине, где винт большой, при создании образа она просто виснет наглухо, ничего не делая. Ей можно сказать, чтобы она делала образ локально на другом винте, а не на сервере – не вопрос, после этого она образ делает, но при загрузке с него виснет после старта SMSS. Может, ей не нравятся дрова сетевухи, разбираться желания особо не было. Зато рисует красивый сплэшик при загрузке. Кг/ам.

Сопутствующий геморрой

Загрузка по сети подразумевает, как минимум, DHCP, и вот тут лежат занятные грабли фигурной формы, производства любимой компании МТУ, известные как Стрим-ТВ. Стрим-ТВ использует два дополнительных ATM VCC, которые оба должны бриджиться по 1483 в ту сеть, в которую воткнута приставка. По одному из них ходит обычный IP, а по второму какая-то шняга, которая собственно и есть видео, но я в этих видео делах не копенгаген, так что деталей не знаю. В теории, МТУ предлагает юзерам купить роутер с поддержкой VLAN, которому можно назначить отдельный физический порт на эти VCC и соответственно воткнуть туда приставку отдельным шнурком. На практике это выливается в глючный ASUS или, прости Кришна, мерзкий Huawei, который к тому же еще и фиг купишь – а у D-Link с поддержкой VLAN все плохо. Поэтому простые люди ставят обычный D-Link а-ля 5xx, который умеет несколько VCC, и фигачат эти потоки в общую сеть – ну будет он там броадкастом гадить, восемью мегабитами в гигабитке можно пожертвовать.

Проблема в таком варианте как раз с DHCP. Стримовский декодер хочет получить по DHCP себе стримовский же адрес, и вот тут проблема встает во весь рост. Чтобы все это работало, во внутренней сети DHCP быть не должно, но грузиться по сети хочется. Но в итоге на самом деле все решается просто – D-Link, как выяснилось, умеет делать bridge filter по MAC-адресу, и соответственно можно запретить форвард в определенный VCC со всех мак-адресов, кроме одного, ну и внутреннему серверу запретить давать адреса определенному хосту, после чего настает счастье. Правда, грузить по сети все равно нечего, но зато теперь работает DHCP.

Если гора не идет к Магомету

Если винды нельзя загрузить по сети, то их можно загрузить с чего-нибудь еще, что не издает шума. Естественно, приходит в голову мысль о флеше, но к сожалению, IDE флеш-драйвы делятся на две категории – дешевые и очень маленькие, и чуть побольше, но безумно дорогие. Плюс еще такой фактор, как wear out – если грузить винды с обычного флеша, ему быстро придет каюк вместе с виндами, поэтому драйв должен поддерживать wear out management. Цена вопроса такова – примерно $200 за 4 гига, и ненормальные деньги за каждый байт сверх этого. Кстати, на запись они довольно медленные.

Самый экстремальный вариант – это Gigabyte i-RAM. Это PCI-плата с четырьмя слотами под диммы, SATA-разьемом и аккумулятором. Идея, на самом деле, хотя и выглядит экстремальной, по здравому размышлению начинает казаться довольно привлекательной – как минимум, из-за производительности. Когда %SystemRoot% весь всегда лежит в памяти, это кое-что значит. Но – во-первых, максимальный поддерживаемый обьем – 4 гига, то есть запихать туда даже %SystemRoot% – в условиях нормальной рабочей винды – крайне проблематично. Во-вторых, PCI-слот, из которого она берет, кстати говоря, только питание. Лично в моем случае она займет единственный свободный, что означает, что мне придется выкинуть звуковуху, чтобы освободить слот – который нужен по делу – и извращаться с внешней. В-третьих, цена вопроса – опять $200, не считая собственно диммов.

Заключение: всё говно. Пойду куплю цианид. Автор статьи 1ceheart

2 комментов оставлено (Add 1 more)

  1. Здравствуйте!
    У меня простой вопрос кто своими руками делал вышеописанное в варианте с применением АОЕ?
    Откликнитетесь через мое мыло papont2007@ukr.net.
    Есть несколько вопросов над которыми ломаю голову!
    Заранее спасибо!
    зфзщте2007

    2. papont2007 on May 21st, 2008 at 12:51 pm
  2. Небольшое дополнение. По просьбе Etherboot’а, Software Freedom Law Center, провел исследование на возможность использования проприетарного iBFT от Microsoft в опенсорс продуктах. Мнение SFLC: “никаких препятствий по использованию нет”. Более того, в августе 2007-го IBM выпустило собственную спецификацию iBFT под GPL, которую и стал использовать etherboot. Так, что возможность грузить W2k3 по ISCSI и XP по AoE имеется.

    3. as65sd on April 8th, 2008 at 8:39 am

One Trackback

  1. By watch jordan on redmixer.net on May 14, 2012 at 9:50 pm

    watch jordan on redmixer.net…

    [...]бездисковая загрузка, DHCP | Для системного администратора[...]…