Ну, это не совсем так. ESXi использует .vswp (производит в него запись и читает из него) только в том случае, когда у него (гипервизора) не хватает памяти для выделения VM в полном объема её запроса, и включается этот механизм последним (если TPS ничего не сэкономил, если не помог balooning. Так что в нормальной ситуации (когда нет переподписки по RAM) этот файл .vswp равен по размеру памяти VM, но в нём ничего нет, это просто размеченный файл на VMFS. Если сделать полное резервирование памяти для VM, этот файл вообще будет по размеру околонулевым, что логично, ведь резервированием RAM вы гарантируете выделение для VM памяти в полном объёме (если есть demand) при любых ситуациях, и хост не будет свапать на диск вытесненные страницы. Но от этого ведь вообще ничего не изменится в госте с точки зрения работы со свап файлом (будь то linux или windows). Короче, корреляция между свапами гостей и свапом VM со стороны гипервизора примерно никакая.
Я тут выше немножко расписал. Но вот два примера:
1. Вы дали машине 8GB RAM, запустили, внутри гостя (например, венда) создается swap-файл, т.е. внутри VMDK, прям на файловой системе (скажем, NTFS). И вот приложение в вашем госте начинает требовать больше, чем вы дали машине. У гипервизора свободной памяти в достатке, но VM страдает просто из-за мисконфигурации. А вот начинается активная запись в swap и чтение из него (тот, который внутри гостя на NTFS лежит). Машине плохо, но гипервизор в этом не виноват;
2. Вы дали машине 8GB RAM, запустили. Demand у неё 6GB, и ей этих 8 хватает. Внезапно у гипервизора перестаёт хватать памяти для неё (из-за noisy neighbour'а, например) и он может выделить только 2, а вот нужные 6 не может. И вот если не спасают всякие танцы TPS (который если современный, с солью, и его не конфигурировали, то сильно он не сдедуплицирует), не помог balooning, то в последнюю очередь начинает работать swap на уровне гипервизора и он пишет туда данные вытесненных страниц памяти. Это когда уже у ESXi не хватает памяти для VM. Этот файл .vswp создается на датасторе vSphere в каталоге VM, а не внутри гостя (не в вашей венде). Это крайний случай механизмов экономии памяти, он работает последним и если он запустился, то это плохо. Более того, даже приходится делать ручной unswap (или ребут хехе), но это уже другая история. В общем, этот .vswp файл по размеру соответствует размеру памяти VM (сконфигурированной памяти), что логично. Но при достаточном количестве ресурсов он не активен, т.е. запись в этот файл не ведется, как нет и чтения из него.
Так вот, если у гипервизоров массово не хватает памяти для VM, и .vswp файлы активно пишутся и читаются, то вас вряд ли спасёт даже современный all-flash массив.
Начнём с того, что статья «немножко устарела». С такими вещами, как vCD (да и вообще продукты VMware) зачастую нет смысла читать статьи такого возраста. Блин, даже дисковые и cpu шедулеры меняются.
А вот по существу: создание .vswp это поведение vSphere, а не vCD. Логично, что при отсутствии резервирования памяти, размер этого файла будет равен размеру памяти VM. Ключевой момент в том, что это своп уровня гипервизора, а не уровня гостя, т.е. vswp read/write происходит в том случае, когда у гипервизора не достаточно RAM для предоставления VM (если со стороны VM есть «demand»). Т.е. .vswp не будет и не должен работать, если имеет место мисконфигурация VM и её дали памяти сильно меньше, чем нужно гостю. Если сделать полное резервирование памяти, то файл .vswp на датасторе всё равно будет создан, но он будет минимального размера.
Теперь о vCD: при создании машин от команды vCD (а не напрямую в vSphere) резервирование памяти для VM не предусмотрено. Есть резервирование на уровне Resource Pool, который фактически является vCD Organization VDC. Пример: вы купили 1 TB памяти с 20% резервированием с моделью Allocation Pool. Это значит, вы можете создать машины с суммарной сконфигурированной RAM 1 TB. Создаёте машину с 64 GB RAM, и на ресурс пул приземляется Reservation 20% от 64, т.е. 12800 (а не сразу 200 GB, что есть 20% от 1TB). А вот на уровень VM резервирование не прилетает. Это нормальное поведение vCD (правда, я давно не интересовался моделью reservation и совсем не интересовался flex).
И более того, даже если вы заразерервируете память на уровне VM, vCD на это плевать и он зачтёт размер памяти в requested storage. Емнип, у vCD в схеме базы даже нет полей с данными резервирования compute ресурсов на уровне именно VM. Т.е. при синке inventory он этих данных от vCenter'а не получает, да ему и не зачем (типа логика «облачности» тогда страдает, ну вот эта вот философия, ага). Пример: создали вы VM 40GB диск, 40 GB RAM. Вам админ vSphere зарезервировал всю память на этой VM (за красивые глаза), включаете. Но Requested Storage на Storage Policy всё равно будет 80 GB. Это точно справедливо для vCD 9.1 и 9.5 (уверен, что для 9.7 и 10 в этом плане ничего не поменялось).
Как я отметил выше, одной из важнейших черт является обслуживание vm i/o стека, ESXi тут вообще в отдельную категорию вываливается, но и Hyper-V с Xen`ами отличаются от виртуалбоксов.
P.S. Выделяя жирным это «админил entrprise» вы меня напугать хотите? Мидл-рэндж массивами и шассями c7000? Их есть у меня и были всякие.
Дискутировать о виртуализации с представителем шарашкиной госконторы, которая давит конкуренцию на рынке, выдавая сертификаты дерьмовым решениям, которые стоят не дешевле лидеров мирового рынка? Знаете толк. Всякие там vExpert`ы (Ник Маршалл, например) тоже подразделяют гипервизоры на типы, например, по признаку того, «творится» ли виртуализация посредством ядра/модуля ядра или софтом (ну, там отдельный application layer часто рассматривается), как обслуживается vm i/o стэк — через «parent partition» или каким другим способом и т.д. Есть мнение, что эти вот vExpert`ы и прочие VCDX`ы чуть лучше знают.
Я, конечно, не в курсе по поводу больших там ЦОДов, но на сколько эта фраза реальна:
Системы Lenovo используются в 6 из 7 крупнейших в мире ЦОД.
? Я вижу небольших пользователей (сам один из таких), которые используют до 10 — десятки машин, а не сотни/тысячи, но большинство из тех, кого я знаю, предпочитает HPE. Однозначно, моя точка зрения однобока и субъективна, но как тогда HPE не загибается и даже растет? Да и не только HPE, но и все остальные вендоры, если lenovo такие популярные, прям ранк1? Просто интересно узнать реальное положение дел, у меня и правда сложилось впечатление, что в малых и средних масштабах хьюлетт значительно популярнее всех остальных, неужели в больших масштабах все кардинально иначе?
Мидл это мидл, синьор это синьор, в конторке из 10 человек не бывает мидлов, бывают технические специалисты, которые решают какие-то проблемы за 5 копеек денег, потому что в таких конторах к ИТ относятся по остаточному принципу.
Сегодня, учитывая количество технологий, их сложность и «наслаиваемость» трудно найти мидла, тем более реального синьора. А синьору, который умеет все то, что вы там написали про гиты/скрамы/c-плюс-плюсы, можно поручить решение проблемы перенаселения земли, он и с ней справится.
Я так и вижу мидла, который шарит в сетях хотя бы на уровне между ccna и ccnp (в достаточно большой организации по-любому как ccnp), достойно разбирается хотя бы в одной среде виртуализации, достойно разбирается в одной классической платформе ОС (Windows или *nix), достойно разбирается в хранении данных (сюда СХД, резервное копирование, SAN, если это FC, то как минимум FC фундаменталс нужно знать, brocade cli и всякое там) и так, между делом, изучил остальной список из 10 пунктов. ОК. И я забыл про всякие «незначительные» мелочи вроде служб каталогов, систем мониторинга, и прочей сопутствующей мишуры.
Не знаю на счет старости, мне 28 и для меня это выглядит как маркетинговые понты. Какой-то модный тренд, который не дает четкого понятия, какие у человека должны быть компетенции, чем он конкретно должен заниматься и в какой области. Звучит как специалист по всему, а специалист по всему — это специалист по ничему.
BTW, помню слушал подкаст с linkmeup, касающийся автоматизации работы сетевых инженеров с помощью ансиблов/питонов, там участвовали Наташа Самойленко, был еще один CCIE из Cisco TAC (может и больше, но один точно был), был сотрудник амазона и, кажется, eucariot. И кроме вопросов а-ля «а нужно ли сетевому инженегру писать скрипты» всплыл вопрос про devops. Говорилось о том, что встречается довольно большое количество вакансий «девопс». Так вот, на сколько я понял из подкаста, они вот тоже не очень уверены, что это точно такое, короче, пропорции условны, а границы размыты.
P.S. а может я просто быдло и не понимаю визионерских тенденций.
Если вы имеете в виду физический vCenter — то это не то что бы неправильный вариант, но точно не лучшая практика. Собственно, сама VMware рекомендует делать vCenter виртуальным. На вскидку плюсы:
1. При обслуживании физической машины не будет простоя службы vCenter — смигрировали на другой гипервизор и все ок. В случае физического vCenter при обслуживании простой есть (надо же таки FW обновлять и т.д.)
2. Виртуальный vCenter защищен HA (после настройки HA vCenter не нужен для работы этого механизма).
3. Виртуальную машину однозначно проще бэкапить и восстанавливать чем физику. Как бэкапить vCenter на физике? Отдельно файловый бэкап, отдельно базу, и потом после восстановления надеяться что это заведется?
4. Если vCenter у вас на физике, то ОС будет на DAS скорее всего, да? В случае виртуального vCenter vm будет на двухконтроллерном массиве (ну, это в мало-мальском Ынтерпрайзе).
Это то, что сходу в голову пришло. Причин держать на физике не вижу ни одной.
я как бы намекаю на то, что nexus больше не поддерживается в vsphere.
По поводу NSX: я не шибко в курсе фич продукта, поэтому не уверен, заменяет ли он нексус, но вот в чем я уверен: я не хочу отдельно за него платить и изучать его. Нексус ess был бесплатным, advanced — $700 per processor. NSX std — $2k.
Импортозамещение — это то, что навязывается в гос сегменте и иже с ними (военка/муниципальные органы/органы гос. власти/органы зак. власти/силовые структуры и т.д.).
Несмотря на то, что четкого плана «импортозамещения» для всех регионов еще нет, все же в плане софта импортозамещением считается именно то ПО, которое есть в реестре отечественного ПО reestr.minsvyaz.ru/reestr. А на самом ли деле оно разработано в России, уже никого не волнует. Например Altell NEO — сертифицированный ФСТЭК программный межсетевой экран. Ну как, это ПАК и к реестру ПО отношения не имеет, но вы прекрасно понимаете что это софт, а не асик. А на самом деле там опоганенная клевыми программистами Vyatta с нерабочими ids/ips и много чем еще (даже NTP сервер не работает, лол). Шутка в том, что Altell даже разогнал весь штат саппорта, мне отвечали на кейсы по 5-6 месяцев. Ну как отвечали, отписывались, но ни одного рабочего решения не предложили. Ну и как «отвечали», на самом деле «отвечал», там один человек работает. Вот что такое пользоваться одобренными/сертифицированными решениями в России. Какой-то чувак мутит стартап, нанимает пару программеров за 3 печеньки, они меняют лэбйлы опенсорсного решения на кириллицу, а его дядя пробивает, сертификат или место в реестре отечественного ПО. Как оно там, «х*як-х*як и в продакшн»? Вот так все и делается, пускай не в каждом первом случае, но в двух случаях из трех. А еще одна замечательная шутка это цена. Стоит Altell NEO UTM 210 в полной «комплектации» (т.е. с не закрытыми ovpn и прочими стандартными фичами) 350-400 т.р. Производительность железки можно посмотреть на сайте, но это маркетинговый буллшит, фактически там 6 гиговых интерфейсов, младший xeon и ЕМНИП 6 ГБ RAM и позиционируется как железка для организации на ~150-200 чел (интересный показательный параметр). Вот так вот. Софтверное решение на базе опенсорса по цене решений из топа Гартнер, а ля CheckPoint или ASA. Стоит ли говорить, что я могу купить такую железку меньше чем за 100к руб и занести туда свободный форк Vyatta — vyos.
А касательно оборудования — замечена интересная тенденция. Интеграторы начали регистрироваться как производители HW, заключают специальные договоры с реальными производителями и клеят свои лэйблы на их железо. ОЕМят их, так сказать. Я знаю по крайней мере один пример, контора лепит свою наклейку на Dell сервера. А вот DEPO лепит свой лэйбл на EMC Data Domain.
Вот что такое импортозамещение по-русски. Конечно, не все подряд так делается, но ОЧЕНЬ многое. Есть те, кто реального делали железо еще до этой охоты на ведьм (читай на зарубежные решения), но сейчас у дельцов есть реальная возможность делать неконкурентоспобосное дерьмо и впаривать его тем, кто обязан импортозамещаться. И я это не из прочитанного в интернетах заявляю, а из увиденного в реальной жизни.
Если кто-то из подведомственных/семейных организаций будет находиться в поисках решения для резервного копирования, то, я думаю, мы рассмотрим акронис более детально. Признаюсь, когда я тестировал эту систему, я был предубежден против неё. Хотя не столько против системы, сколько против бредового решения одного из руководителей, который при купленном veeam ent на 44 (!) сокета, при чем купленном еще за доллары по 35, решил рассмотреть вариант замены системы резервного копирования (с покупкой саппорта читерим, да).
Кстати, по поводу транспорта: я не помню точно, но, кажется, не нашел варианта транспорта lan free, т.е. трансфер резервных копий via SAN (DirectSAN Access). Есть такое у акрониса или планируется?
Про массив не узнал ничего, кроме того, что он, вроде, архитектурно неглупо выполнен. Как, собственно, и у любого приличного вендора. Ни фич, ни цен с лицензированием, ни описания менеджмент интерфейса. Зато есть упоминание про какой-то дедуп рэйт (который часто воображаемый, т.е. маркетинговый). В продуктивной схд дедуп, кажется, не самая популярная вещь, по крайней мере для плебеев вроде меня, которым кажется что i/o потенциал важнее дедупликации. Импакт же все таки должен быть? Хотя я, конечно, не специалист, а просто наблюдатель. Однако, когда видишь статью про первое xxx в Россиии, хочется прочитать про что-то, кроме монтажа.
Зато на девушку посмотрел и на лисов в комментариях. Как будто имэдж борду какую-то посетил.
Таки да, не успел. Может кто-нибудь порекомендовать "оффлайн" языковую школу в Москве?
1. Вы дали машине 8GB RAM, запустили, внутри гостя (например, венда) создается swap-файл, т.е. внутри VMDK, прям на файловой системе (скажем, NTFS). И вот приложение в вашем госте начинает требовать больше, чем вы дали машине. У гипервизора свободной памяти в достатке, но VM страдает просто из-за мисконфигурации. А вот начинается активная запись в swap и чтение из него (тот, который внутри гостя на NTFS лежит). Машине плохо, но гипервизор в этом не виноват;
2. Вы дали машине 8GB RAM, запустили. Demand у неё 6GB, и ей этих 8 хватает. Внезапно у гипервизора перестаёт хватать памяти для неё (из-за noisy neighbour'а, например) и он может выделить только 2, а вот нужные 6 не может. И вот если не спасают всякие танцы TPS (который если современный, с солью, и его не конфигурировали, то сильно он не сдедуплицирует), не помог balooning, то в последнюю очередь начинает работать swap на уровне гипервизора и он пишет туда данные вытесненных страниц памяти. Это когда уже у ESXi не хватает памяти для VM. Этот файл .vswp создается на датасторе vSphere в каталоге VM, а не внутри гостя (не в вашей венде). Это крайний случай механизмов экономии памяти, он работает последним и если он запустился, то это плохо. Более того, даже приходится делать ручной unswap (или ребут хехе), но это уже другая история. В общем, этот .vswp файл по размеру соответствует размеру памяти VM (сконфигурированной памяти), что логично. Но при достаточном количестве ресурсов он не активен, т.е. запись в этот файл не ведется, как нет и чтения из него.
Так вот, если у гипервизоров массово не хватает памяти для VM, и .vswp файлы активно пишутся и читаются, то вас вряд ли спасёт даже современный all-flash массив.
Ну вот это вот на пальцах так, кратко.
А вот по существу: создание .vswp это поведение vSphere, а не vCD. Логично, что при отсутствии резервирования памяти, размер этого файла будет равен размеру памяти VM. Ключевой момент в том, что это своп уровня гипервизора, а не уровня гостя, т.е. vswp read/write происходит в том случае, когда у гипервизора не достаточно RAM для предоставления VM (если со стороны VM есть «demand»). Т.е. .vswp не будет и не должен работать, если имеет место мисконфигурация VM и её дали памяти сильно меньше, чем нужно гостю. Если сделать полное резервирование памяти, то файл .vswp на датасторе всё равно будет создан, но он будет минимального размера.
Теперь о vCD: при создании машин от команды vCD (а не напрямую в vSphere) резервирование памяти для VM не предусмотрено. Есть резервирование на уровне Resource Pool, который фактически является vCD Organization VDC. Пример: вы купили 1 TB памяти с 20% резервированием с моделью Allocation Pool. Это значит, вы можете создать машины с суммарной сконфигурированной RAM 1 TB. Создаёте машину с 64 GB RAM, и на ресурс пул приземляется Reservation 20% от 64, т.е. 12800 (а не сразу 200 GB, что есть 20% от 1TB). А вот на уровень VM резервирование не прилетает. Это нормальное поведение vCD (правда, я давно не интересовался моделью reservation и совсем не интересовался flex).
И более того, даже если вы заразерервируете память на уровне VM, vCD на это плевать и он зачтёт размер памяти в requested storage. Емнип, у vCD в схеме базы даже нет полей с данными резервирования compute ресурсов на уровне именно VM. Т.е. при синке inventory он этих данных от vCenter'а не получает, да ему и не зачем (типа логика «облачности» тогда страдает, ну вот эта вот философия, ага). Пример: создали вы VM 40GB диск, 40 GB RAM. Вам админ vSphere зарезервировал всю память на этой VM (за красивые глаза), включаете. Но Requested Storage на Storage Policy всё равно будет 80 GB. Это точно справедливо для vCD 9.1 и 9.5 (уверен, что для 9.7 и 10 в этом плане ничего не поменялось).
P.S. Выделяя жирным это «админил entrprise» вы меня напугать хотите? Мидл-рэндж массивами и шассями c7000? Их есть у меня и были всякие.
? Я вижу небольших пользователей (сам один из таких), которые используют до 10 — десятки машин, а не сотни/тысячи, но большинство из тех, кого я знаю, предпочитает HPE. Однозначно, моя точка зрения однобока и субъективна, но как тогда HPE не загибается и даже растет? Да и не только HPE, но и все остальные вендоры, если lenovo такие популярные, прям ранк1? Просто интересно узнать реальное положение дел, у меня и правда сложилось впечатление, что в малых и средних масштабах хьюлетт значительно популярнее всех остальных, неужели в больших масштабах все кардинально иначе?
P.S. сам испытывал весьма положительные эмоции от эксплуатации system x (в блейдцентре), пока не попробовал hpe bl (в блейдцентре).
P.P.S. www.idc.com/getdoc.jsp?containerId=prUS42335617
Сегодня, учитывая количество технологий, их сложность и «наслаиваемость» трудно найти мидла, тем более реального синьора. А синьору, который умеет все то, что вы там написали про гиты/скрамы/c-плюс-плюсы, можно поручить решение проблемы перенаселения земли, он и с ней справится.
Я так и вижу мидла, который шарит в сетях хотя бы на уровне между ccna и ccnp (в достаточно большой организации по-любому как ccnp), достойно разбирается хотя бы в одной среде виртуализации, достойно разбирается в одной классической платформе ОС (Windows или *nix), достойно разбирается в хранении данных (сюда СХД, резервное копирование, SAN, если это FC, то как минимум FC фундаменталс нужно знать, brocade cli и всякое там) и так, между делом, изучил остальной список из 10 пунктов. ОК. И я забыл про всякие «незначительные» мелочи вроде служб каталогов, систем мониторинга, и прочей сопутствующей мишуры.
BTW, помню слушал подкаст с linkmeup, касающийся автоматизации работы сетевых инженеров с помощью ансиблов/питонов, там участвовали Наташа Самойленко, был еще один CCIE из Cisco TAC (может и больше, но один точно был), был сотрудник амазона и, кажется, eucariot. И кроме вопросов а-ля «а нужно ли сетевому инженегру писать скрипты» всплыл вопрос про devops. Говорилось о том, что встречается довольно большое количество вакансий «девопс». Так вот, на сколько я понял из подкаста, они вот тоже не очень уверены, что это точно такое, короче, пропорции условны, а границы размыты.
P.S. а может я просто быдло и не понимаю визионерских тенденций.
1. При обслуживании физической машины не будет простоя службы vCenter — смигрировали на другой гипервизор и все ок. В случае физического vCenter при обслуживании простой есть (надо же таки FW обновлять и т.д.)
2. Виртуальный vCenter защищен HA (после настройки HA vCenter не нужен для работы этого механизма).
3. Виртуальную машину однозначно проще бэкапить и восстанавливать чем физику. Как бэкапить vCenter на физике? Отдельно файловый бэкап, отдельно базу, и потом после восстановления надеяться что это заведется?
4. Если vCenter у вас на физике, то ОС будет на DAS скорее всего, да? В случае виртуального vCenter vm будет на двухконтроллерном массиве (ну, это в мало-мальском Ынтерпрайзе).
Это то, что сходу в голову пришло. Причин держать на физике не вижу ни одной.
По поводу NSX: я не шибко в курсе фич продукта, поэтому не уверен, заменяет ли он нексус, но вот в чем я уверен: я не хочу отдельно за него платить и изучать его. Нексус ess был бесплатным, advanced — $700 per processor. NSX std — $2k.
Импортозамещение — это то, что навязывается в гос сегменте и иже с ними (военка/муниципальные органы/органы гос. власти/органы зак. власти/силовые структуры и т.д.).
Несмотря на то, что четкого плана «импортозамещения» для всех регионов еще нет, все же в плане софта импортозамещением считается именно то ПО, которое есть в реестре отечественного ПО reestr.minsvyaz.ru/reestr. А на самом ли деле оно разработано в России, уже никого не волнует. Например Altell NEO — сертифицированный ФСТЭК программный межсетевой экран. Ну как, это ПАК и к реестру ПО отношения не имеет, но вы прекрасно понимаете что это софт, а не асик. А на самом деле там опоганенная клевыми программистами Vyatta с нерабочими ids/ips и много чем еще (даже NTP сервер не работает, лол). Шутка в том, что Altell даже разогнал весь штат саппорта, мне отвечали на кейсы по 5-6 месяцев. Ну как отвечали, отписывались, но ни одного рабочего решения не предложили. Ну и как «отвечали», на самом деле «отвечал», там один человек работает. Вот что такое пользоваться одобренными/сертифицированными решениями в России. Какой-то чувак мутит стартап, нанимает пару программеров за 3 печеньки, они меняют лэбйлы опенсорсного решения на кириллицу, а его дядя пробивает, сертификат или место в реестре отечественного ПО. Как оно там, «х*як-х*як и в продакшн»? Вот так все и делается, пускай не в каждом первом случае, но в двух случаях из трех. А еще одна замечательная шутка это цена. Стоит Altell NEO UTM 210 в полной «комплектации» (т.е. с не закрытыми ovpn и прочими стандартными фичами) 350-400 т.р. Производительность железки можно посмотреть на сайте, но это маркетинговый буллшит, фактически там 6 гиговых интерфейсов, младший xeon и ЕМНИП 6 ГБ RAM и позиционируется как железка для организации на ~150-200 чел (интересный показательный параметр). Вот так вот. Софтверное решение на базе опенсорса по цене решений из топа Гартнер, а ля CheckPoint или ASA. Стоит ли говорить, что я могу купить такую железку меньше чем за 100к руб и занести туда свободный форк Vyatta — vyos.
А касательно оборудования — замечена интересная тенденция. Интеграторы начали регистрироваться как производители HW, заключают специальные договоры с реальными производителями и клеят свои лэйблы на их железо. ОЕМят их, так сказать. Я знаю по крайней мере один пример, контора лепит свою наклейку на Dell сервера. А вот DEPO лепит свой лэйбл на EMC Data Domain.
Вот что такое импортозамещение по-русски. Конечно, не все подряд так делается, но ОЧЕНЬ многое. Есть те, кто реального делали железо еще до этой охоты на ведьм (читай на зарубежные решения), но сейчас у дельцов есть реальная возможность делать неконкурентоспобосное дерьмо и впаривать его тем, кто обязан импортозамещаться. И я это не из прочитанного в интернетах заявляю, а из увиденного в реальной жизни.
Да, пригорело-с.
Кстати, по поводу транспорта: я не помню точно, но, кажется, не нашел варианта транспорта lan free, т.е. трансфер резервных копий via SAN (DirectSAN Access). Есть такое у акрониса или планируется?
Зато на девушку посмотрел и на лисов в комментариях. Как будто имэдж борду какую-то посетил.