В процессе рысканья по инету, обнаружил еще одного интересного хостера, который в том числе реселлит дедики от Burst.NET. Хостинг именуется Inferno Solutions и помимо русской поддержки имеет неоспоримое преимущество среди многих русскоязычных хостингов- это реселлер зарубежных площадок, то есть они берут в аренду гарантированно рабочее оборудование, накидывают небольшую маржу и толкают их со своей поддержкой, которая является так называемым тир1 суппортом. То есть все что могут делают сами, если сталкиваются с какими то проблемами, то эскалируют уже хостеру. И судя по отличным отзывам в рунете, справляются со своими обязанностями на твердую пятерку. И на этом можно было бы закончить это пост, снабдив его ссылкой перехода на хостинг VPS и выделенных серверов (которые у них, кстати, предлагаются по очень и очень приемлемым ценам); если бы не одно но.
В своей рекламе, хостинг Inferno Solutions пользует старинную формулу “це не бага, це фича”, порождающую нормальную холивару, которую я и хочу разобрать в том посте.
В своих рекламных слоганах, хостинг упирается в то, что их клиенты защищены от так называемого оверселлинга (overselling), или избыточного использования мощности VPS сервера, когда администратор сервера закладывает в совокупную мощность виртуальных серверов хоста, больше чем имеется ресурсов в системе, то есть при 4 GB оперативы (оверселить можно также и полосу пропускания канала, дисковое пространство), она распределяется по 512Mb не между 6 машинами, по 512Gb на гестов и 1Gb на хостовую часть, а между 20 машинами, которые дергают мощности друг у друга. На этом собственно и базируется технология Burst RAM, когда у VPS сервера имеется гарантированная память и burst, которая может кратковременно увеличиваться раза в полтора, при кратковременных нагрузках. Собственно гарантией того, что Inferno Solutions не использует в своих VSP серверах функционал overselling, является использование продукта вируализации Xen, который по заверению хостера невозможно настроить на оверселлинг, как например конкурентный продукт OpenVZ.
По большому счету соперничество OpenVZ и Xen собственно и порождает всю холивару, поскольку и у той и у другой системы имеются сторонники и противники, утверждающие что OpenVZ более изолирована, более безопасна, в то время как Xen быстрее и надежнее, имеет возможность использования swap раздела, ну и всякое и прочее. Помимо этого обе системы, наравне в платным аналогом от VMware (также имеются бесплатные версии с урезанным функционалом), представляют собой разные технологии виртуализации: OpenVZ это модифицированное ядро Linux системы, позволяющее запускать виртуальные среды (то есть ничего кроме линуха); тогда как Xen базируется на перестройке ядра системы, для адаптации работы системы (запускаем что угодно). Скажу откровенно- Xen меня не возбудил, ибо я его ставил пару раз, но мне более импонирует VMware, как в плане настройки, так и в плане идеологии. Кстати, со слов “рекламного слогана”, многие хостеры как раз и выбирают OpenVZ в связи с простотой настройки системы.
Но основным камнем преткновения всегда оставался функционал overselling или burst ram, который отсутствовал в Xen и присутствовал в OpenVZ, и который считался, многими сторонниками Xen, как недостаток продукта OpenVZ. Но видимо команда Xen, ко многим не относится, так как они полагая от обратного, начиная с версии Xen 3.3 внедрили функционал, позволяющий забирать оперативную память гестами и хостовой станции. Называется этот функционал Memory Overcommit, и именно он позволяет забирать память у работающих гестов (или доменов пользуясь терминологией Xen), в случае если эта память ими в данный момент не используется. Механизм использующийся при этом, зовется ballooning, который представляет собой специфический драйвер инсталяющийся в систему и предоставляющий доступную память домена, при запросе от гипервизора Xen.
При этом память, выделенная другому домену, будет числиться в системе, но в виде занятой, что можно проверить соответствием команд # free# ps aux и # top.
Ну и само наличие механизма ballooning в системе, можно увидеть по листингу следующей команды: # cat /proc/xen/balloon
При этом также имеется дополнительный демон xenballoond, написанный на баше, который поддерживается два механизма: selfballooning и direct ballooning, в которых назначение доступной памяти осуществляется из самого домена (но полагаю, что хостеры данные механизм навряд ли буду использовать).
Так что использование или не использование overselling в случае использования любой среды виртуализации, остается на совести хостера, и этот момент желательно выяснять еще на уровне приобретения того или иного тарифного плана. Надо полагать, что Inferno Solutions следуют своей рекламе и не занимаются накруткой статсов VPS серверов, тогда как хостер и регистратор GoDaddy особенно даже и не скрывает данного функционала.
Напоследок надо отметить, что overselling у нормального хостера должен отражаться на цене, в сторону её уменьшения.
Забавная тут ситуевина приключилась с одним сервисом, который я настраивал для клиента. Поднимал Help Desk- первоначально на своей машине в виртуальном окружении VMware Workstation, после чего установил на клиентскую машину VMware Player и перенес машину. Надо отметить что виртуальная машина крутится под Cent OS, а сервер под Win 2003, так что никаких особых проблем не ожидалось.
Но в процессе запуска- выяснилось что машинка не подхватывает IP адрес по DHCP, при работе в bridged mode, а при попытке задать статический IP я получал ругань на тему того, что данный IP уже используется, при том что данный адрес был однозначно свободен. Озадачившись данной проблемой проверил на всякий случай фаервол винды, но как оказалось он был отключен. Поковырявшись в меру возможностей в серваке и vmware, решил не озадачивать клиентского админа, а переставил Player на Workstation и попробовал поднять виртуалку в таком варианте. Но проблема осталась той же самой, при этом когда я переключил сетки в NAT вариант- поднимался внутренний IP и все начинало нормально шуршать.
В итоге обратился к админу с описанием проблемы и предположением о том, что какая то тулза препятствует нормальному прохождению пакетов, выступая видимо фаерволом. Поковырявшись, админ сказал что обнаружил что на серваке зачем то был установлен, тысячу лет назад, kerio vpn client, который он благополучно снес. После данной манипуляции все зашуршало прекрасно, так что причина крылась именно в kerio vpn client который видимо как любой ipsec клиент имеет встроенный фаервол у которого имеются свои взгляды на прохождение пакетов. У клиента от checkpoint, например, таких проблем замечено не было.
Продолжаю биццо с VMware- не думал что в системе может быть столько подводных камней: поставил серваки, все настроил- пришло время создавать дополнительные тома. И тут выясняется, что я не могу создать том размером более 256Gb.
И так пытался, и так- ничего не выходит, как ни стараюсь. Если ставлю размер тома более 256Gb система ругается, что создать не может, и сама автоматом ставит на 256Gb. Стал рыть- выясняется интересная особенность, что максимально возможный размер создаваемого тома зависит от величины размера блока VMFS тома- первый дефолтный лимит для тома составляет 255GB, при размере блока 1MB, при увеличении размера блока, также увеличивается возможный размер тома:
1MB размер блока = максимальный размер VMDK 256GB
2MB размер блока = максимальный размер VMDK 512GB
4MB размер блока = максимальный размер VMDK 1024GB
8MB размер блока = максимальный размер VMDK 2048GB/512bytes
Единственный возможный вариант изменить размер блока- отформатировать LUN с новым размером блока, ибо он задается при форматировании. Сижу втыкаю, думаю что делать.
Поскольку парень я ленивый и ставить снова винду, по второму разу меня совершенно не улыбает, то сначала форматирую пустой массив, используя размер блока 8Mb, а затем загружаю первый datastore, и в нем нахожу галочку смувить папку, в которой и лежит операционка, на другой доступный том. Мувлю (трансфер порядка 60 гиг занимает около 30 минут) сначала одну операционку, потом вторую. После этого форматирую первый datastore опять же с использованием размера кластера в 8Mb. После этого создаю два тома размерами по 800Gb и в 1200Gb.
Ставил у клиента сервак. Решили сделать из одного два, ибо шибко крутой прикупили клиенты, так чтобы не было избыточных мощностей, пришли к выводу что будет виртуализовывать и поднимать парочку. Собственно сконфигурил том в рейде, на 2.8 TB, запустил инсталлер VMware ESXi 4.1. Все поставилось быстренько, установил гипервизора, захожу в консоль, немного ковыряюсь с настройками сервера, и начинаю ставить Windows 2008.
Но тут возникает интересный момент- система видит единственный datastore размеров в 800Gb, и все. То есть в девайсах показывает что есть рейд контроллер, есть рейд массив на 2.8TB, но попытка обнаружения новых datastore не увенчивается успехом, так что в системе доступны только 800 гиг. Гуглю, лезу по форумам и обнаруживаю интересный момент, что VMware не может создавать хранилища больше двух террабайт, то есть у системы VMware и имеется ограничение на создание файлов размером более 2TB.
Чертыхаюсь, перегружаюсь- вижу что VMware видит том на аппаратном уровне, так что попытка разбить его на слайсы сразу будет увенчана неудачей. Собственно залезаю снова в рейдовский биос, сношу том и нарезаю его двумя кусками в 900Gb и 1900GB, после чего запускаю снова инсталлер. VMware видит оба куска, и я ставлю её на тот что размером 900Gb. Все устанавливаю, загружаю систему, подключаюсь гипервизором- все замечательно: в системе два хранилища данных datastore, размерами в 900Gb и 1900Gb.
Резюме: Система виртуализации VMware ESXi не может создавать хранилища данных LUN размером превосходящие 2TB, в данном случае сказывают ограничения по размеру создаваемого файла. При этом если том превышает своими размерами 2TB, то система берет то количество дискового пространства, которое выходит за пределы 2TB и из них создает хранилище, отбрасывая 2TB за ненадобностью. В этой связи единственный способ борьбы- нарезка имеющегося дискового пространства массивами не превышающими 2TB, в этом случае VMware подхватывает их без проблем, и нарезанные массивы подключаются к настроенным системам, средствами VMware путем добавления новых дисков.
Столкнулся с интересной темой в Windows Server 2003, при попытке подключиться к ESX серверу с помощью VMware vSphere Client. При вводе логина клиент выдает ошибку “Error parsing the server “SERVER IP” “clients.xml” file. Login will continue, contact your system administrator” и после нажатия на ОК вываливается во вторую ошибку “The type initializer for “VirtualInfrastructure.Utils.HttpWebRequestProxy” threw an exception”. То есть подключение к серверу недоступно.
Сначала было решили что это проблема с доступом, но просмотрев логи, убедились что мой клиент даже не стучится к серверу, так что стал копать в другую сторону и обнаружит что эту ошибку выдает Windows 7, при использовании стандартного клиента. В этой связи я всял совместимого с Windows 7 клиента VMware-viclient-all-4.0.0-208111 и обновил с его помощью имеющегося.
Ошибка исчезла, так что по видимому была вызвана каким то из последних обновлений для Windows систем.
В данный момент стоит задача протестировать работу двух продуктов класса IPS от компаний ISS и McAfee и сравнить их результаты. Для этого нам необходимо запустить оба этих продукта и натравить на них либо сканер, либо как планируем мы- сканер уязвимостей от того же McAfee Foundstone.
McAfee IntrShield у нас уже есть отлаженный и настроенный, а вот ISS Proventia IPS нужно поставить и для этого инженеры IBM предоставили нам имидж. Но ввиду того что IPS аппаратный комплекс, то имидж представляет собой Boot сервер, с которого устройство, при загрузке должно по DHCP получить IP адрес и после этого по TFTP подтянуть с Boot сервера имидж для перепрошивки устройства. После загрузки, в консоли устройства набираем reinstall и на устройство заливается новая прошивка.
Вообщем встал вопрос, как загрузить виртуальную машину VMware по протоколу TFTP. Для этого запускаем виртуальную машину и тут же входим в консоль и жмем F2 для того чтобы войти в виртуальный биос машины. Там выбираем Boot и плюсиком поднимаем позицию Network boot from AMD Am79C970A наверх. После чего сохраняем и перегружаем машину: все можем спокойно грузить по TFTP.
У операционной системы Windows 7 имеется отличная возможность установить программный модуль совместимости с системой Window XP. Данный модуль позволяет устанавливать программное обеспечение разработанное для Windows XP прямо на Windows 7. Этот функционал позволяет запускать программы старых версий, которые не идут под Windows 7.
Перед установкой следует провести тест оборудование на предмет поддержки аппаратной виртуализации. Данное решение доступно для систем Windows 7 Professional, Enterprise или Ultimate. В том случае если хочется запустить на системах ниже указанных, или же если аппаратная часть не подходит под требования, следует использовать систему виртуализации VMware.
После установки Windows XP Mode функционал будет доступен из Start > All Programs > Windows Virtual PC > Windows XP Mode, после чего запустится настройка окружения.
В процессе рысканья по инету, обнаружил еще одного интересного хостера, который в том числе реселлит дедики от Burst.NET. Хостинг именуется Inferno Solutions и помимо русской поддержки имеет неоспоримое преимущество среди многих русскоязычных хостингов- это реселлер зарубежных площадок, то есть они берут в аренду гарантированно рабочее оборудование, накидывают небольшую маржу и толкают их со своей поддержкой, которая является так называемым тир1 суппортом. То есть все что могут делают сами, если сталкиваются с какими то проблемами, то эскалируют уже хостеру. И судя по отличным отзывам в рунете, справляются со своими обязанностями на твердую пятерку. И на этом можно было бы закончить это пост, снабдив его ссылкой перехода на хостинг VPS и выделенных серверов (которые у них, кстати, предлагаются по очень и очень приемлемым ценам); если бы не одно но.