Главная Virtualization, Новое Зачем же нужна виртуализация?
  • Зачем же нужна виртуализация?

    General Раз уж мы говорим о виртуализации – наверняка у кого-то возникает вполне резонный вопрос: а для чего же это вообще нужно? Оговорюсь, что далее речь пойдет о виртуализации серверов. О виртуализации представлений и приложений – возможно, напишу чуть позже.

    Я, признаться честно, являюсь технарем "до мозга костей", и модные аббревиатуры вроде TCO, ROI, etc., которыми очень любят оперировать господа маркетологи – для меня являются "китайской грамотой". Соответственно – буду писать о том, что я вижу как технарь.

    Наверняка у многих сисадминов в хозяйстве имеется несколько серверов. И обычно это оправданно: многие задачи рекомендуется разносить по разным серверам. К примеру, Microsoft настоятельно не рекомендует совмещать контроллер домена Active Directory и интернет-шлюз на одном физическом сервере. Это создает серьезную угрозу безопасности: в случае атаки на вашу сеть каких-нибудь хакеров или вирусов – первым примет на себя удар, как Брестская Крепость, интернет-шлюз. В случае, если на нем размещался еще и контроллер домена – существует вероятность, что базы AD будут повреждены, либо, что еще хуже – окажутся в руках хакеров. В первом случае понадобится тратить время на восстановление из бэкапов, во втором – очень высокая вероятность дальнейших и более продуманных атак, с использованием логинов и паролей действующих пользователей сети. Ну или просто попадание e-mail адресов пользователей компании в базы спамеров – тоже приятного мало. Одна старая пословица говорит: "Не клади все яйца в одну корзину".

    Соответственно, многие системные администраторы ставят контроллер домена на один физический сервер, а интернет-шлюз – на другой. И это, в принципе – правильно: если гипотетические хакеры атакуют интернет-шлюз, и атака будет успешной – вероятность того, что они проберутся дальше шлюза и получат доступ к другим серверам – много меньше.

    Но тут возникает новая проблема: каждый отдельный сервер – стоит денег, причем не малых (если речь идет о брэндовых серверах). Каждый отдельный сервер потребляет электроэнергию, и занимает место на столе либо в стойке. Возможно, кому-то это покажется не особо актуальным, тем не менее – это является важным преимуществом. Особенно, если сервера размещаются в стороннем датацентре, где взымают плату за занимаемые юниты в стойках и энергопотребление строго ограничивается. К тому же, в европейских странах существует некий налог, который напрямую зависит от объемов электроэнергии, потребляемых компанией. Не помню, как этот налог называется – что-то связанное с экологией и выбросом CO2.

    Кроме этого, каждое из приложений редко потребляет много системных ресурсов: те же контроллеры доменов и интернет-шлюзы – на них редко загрузка процессора превышает 10%. Использование под каждую такую задачу отдельного сервера выглядит нерационально. Совмещать все на одном сервере – как мы уже выяснили, не правильно с точки зрения безопасности. Где же золотая середина? Как же сделать, чтобы и волки были сыты, и овцы целы (и пастуху – вечная память! :)) Ответ дает как раз технология виртуализации.

    Что же такое виртуализация? Виртуализация (а именно – виртуализация серверов) – это технология программной эмуляции аппаратного обеспечения компьютера. Причем, на одной физической машине может быть запущено несколько таких виртуальных "компьютеров". На такие виртуальные машины можно ставить операционную систему и приложения, и работать с ними, как с отдельными физическими машинами. Каждая виртуальная машина использует для своей работы какую-то часть аппаратных ресурсов физической машины. Причем, как правило, объем аппаратных ресурсов, выдаваемых отдельным виртуальным машинам можно регулировать – как жестко (статически), так и динамически. Таким образом, аппаратные ресурсы используются намного более рационально.

    Простой пример: если у нас есть два приложения, которым для работы необходимо 128Мб оперативной памяти, и которые нельзя устанавливать на один физический сервер, можно:

    • 1) Купить два сервера с 128M RAM;
    • 2) Купить один сервер с 256M RAM (плюс еще какое-то количество "про запас" и для запуска хостовой ОС) и запустить оба приложения в отдельных виртуальных машинах.

    Как видно, во втором случае ресурсы сервера (в частности, CPU) используется более рационально, и стоимость р
    ешения гораздо ниже, т.к. один сервер с чуть большим объемом RAM всегда дешевле двух серверов.

    Может показаться, что развертывание нескольких виртуальных серверов на одном физическом – это и есть "класть все яйца в одну корзину", но я все же замечу, что это верно лишь отчасти. Да, при таком развертывании мы все же получаем единую точку отказа в виде одного физического сервера, но тем не менее, все виртуальные машины на физическом уровне изолированы друг от друга и от хостовой ОС. Это проистекает из самой идеологии виртуализации. Соответственно, при, поражении, к примеру, вирусом, одной из виртуальных машин – все остальные машины не будут затронуты его деструктивными действиями, чего трудно избежать при совмещении разных задач на одном сервере, без виртуализации.

    Если же необходимо избежать единой точки отказа – можно купить, к примеру, два сервера и развернуть кластер. В этом случае, два физических сервера будут действовать как единая платформа для виртуализации. Если виртуальных машин, к примеру, 5 – это все равно выгоднее 5и отдельных серверов. А при отказе одного из серверов в кластере – виртуальные машины продолжат работу на другом – вот и все. Пользователи этого скорее всего не заметят. Ну, возможно, прервется у них работа на несколько секунд, это не так критично, как отказ на несколько часов.

    Еще важный момент: виртуализация (если речь идет о решении от Microsoft) поможет сэкономить на лицензиях. К примеру, лицензия на Windows Server 2008 Standard позволяет бесплатно запускать внутри одну виртуальную машину, Enterprise – до 4, а Datacenter – вообще неограниченно (в пределах одного физического хоста).

    Системные администраторы, кстати говоря, оценят и другие удобства виртуализации: быстрота развертывания виртуальных машин и простота резервного копирования.

    Как известно, развертывание нового сервера занимает определенное время. Это – установка ОС, установка драйверов, установка приложений и т.п. Да, конечно, все параметры установки ОС можно задать в файле ответов автоматической установки, драйвера можно интегрировать в дистрибутив, приложения установить, например, через RunOnce, но все равно установка занимает время. Даже если создать полный образ системы – во-первых, его развертывание все равно займет порядка 10-15 минут просто из-за его объема и скорости чтения из сети или с DVD-ROM, во-вторых – для создания такого образа, как правило, необходимо прибегать к помощи стороннего ПО. С виртуальными же машинами все намного проще: можно создавать абсолютно идентичные "клоны" виртуальной машины за пару кликов мышью, и процесс займет порядка нескольких минут – ведь скорость работы дисковой подсистемы сервера намного выше, чем пропускная способность сети или скорость чтения DVD-ROM.

    Приведу пример из собственного опыта. Контора, где я однажды работал, занималась, помимо прочего, и разработкой ПО. Естественно, разработчикам было необходимо где-то тестировать и отлаживать свои программы. Как нельзя лучше для этого подходили виртуальные машины. Благодаря клонированию – удалось создать эталонный образ, в результате которого развертывание новой виртуальной машины занимало порядка 3 минут. А у нас было целых два сервера, на каждом из которых работало примерно по 20 виртуальных машин. К слову сказать – использовался VMWare ESX Server, было просто два отдельных сервера – без VMotion и кластеров. Правда, для управления использовался Virtual Center.

    Еще одна головная боль любого сисадмина – резервные копии. Как утверждает пословица: "Есть два типа сисадминов: те, которые еще не делают бэкапы, и те, которые уже делают". Резервное копирование – на первый взгляд, возможно, кажется бесполезной процедурой, но как только жареный петух куда-нить клюнет – тот, кто не делал бэкапы – начинает рвать на себе волосы, кусать локти и развертывать все заново. Если на сервере уже были какие-то важные данные – это то еще удовольствие. А если там была, например, база данных, содержащая бухгалтерию предприятия за последние 10 лет – то это просто смерти подобно. Не говоря уже, опять же, о простое – который может обернуться серьезными убытками. Ну не поймут клиенты, если им будут говорить "Подождите пожалуйста, у нас сервер не работает!" – они просто пойдут и купят у кого-то другого. Директор, естественно, админа за такое дело по головке не погладит.

    Даже если делается бэкап, то не всегда можно дать 100% гарантию, что из него можно будет восстановить ОС на "голом железе", и она будет работать без ошибок. Особенно – если конфигурация аппаратного обеспечения будет немно
    го отличаться от предыдущей. Близкую к 100%-ной гарантию дают системы резервного копирования, имеющие функцию "Bare Metal Restore" – например, Symantec BackupExec, CA ArcServe, IBM Tivoli Storage Manager, HP Data Protector. Но само это ПО стоит вполне приличных денег, и за функцию "Bare Metal Restore" придется заплатить отдельно: для ее использования, как правило, необходима отдельная лицензия.

    С виртуальными же машинами намного проще: все "железо" там стандартное, ибо эмулируемое, и для полного бэкапа достаточно просто скопировать один или несколько файлов. Всё. Для восстановления достаточно просто скопировать файл(ы) на новый сервер, где уже установлена хостовая ОС со средой виртуализации, и "подцепить" их – и виртуальная машина будет работать как ни в чем не бывало.

    Еще необходимо упомянуть так называемые моментальные снимки (snapshots): это – грубо говоря – бэкап виртуальной машины, хранящийся внутри нее самой. При необходимости можно просто "откатить" виртуалку на момент снятия моментального снимка – и она будет работать, как будто с того момента ничего не изменилось. Причем, у одной виртуальной машины может быть много таких snapshot’ов, и они могут образовывать древовидную структуру. Это позволяет "откатывать" систему ровно к необходимому моменту. Такой функцией могут пользоваться, к примеру, системные администраторы, делая snapshot до и после каких-либо важных изменений, и, если понадобиться, к примеру – откатиться до момента изменений. Или еще раньше. А потом, если надо – позже. И не нужно развертывать систему с нуля и снова повторять все свои действия. Наши разработчики, кстати, по достоинству оценили такую возможность: раньше, когда они использовали VirtualPC на своих рабочих станциях – делать такие "откаты" было затруднительно, часто приходилось создавать машину заново с эталонного образа.

    Итак, подводя итог, вкратце – почему все же виртуализация серверов – это гуд:

    • Рациональное использование аппаратных ресурсов серверов;
    • Экономия денег на покупке новых серверов, экономия электроэнергии и физического пространства;
    • Экономия лицензий на виртуальные ОС (если речь о Microsoft);
    • Простота администрирования: легкость перемещения виртуальных машин с одного физического сервера на другой, быстрота развертывания новой машины из эталонного образа, простота создания резервной копии и восстановления из нее, использование "моментальных снимков".

    Собственно, на этом хотелось бы завершить данную статью.

    Александр Косивченко

    • Рубрика: Virtualization,Новое
    • Автор: Александр Косивченко
    • Дата: Sunday 29 Mar 2009

Комментарии

  1. не все так радужно, особенно с бэкапом и восстановлением, и у vmware и у MS

  2. Ну как бы сказать… Намного радужнее, чем у физических машин: все же виртуалку в общем случае восстановить с бэкапа проще. Что же до VMWare и MS… Если сравнивать ESX и Hyper-V – то в плане бэкапа Hyper-V выигрывает: во-первых, для самого бэкапа не требуются никакие лицензии, в отличие от VMWare ESX, где требуется отдельная лицензия на каждый чих и пук, а во-вторых – сама процедура настройки и использования VMWare Consolidated Backup – задача очень нетривиальная, в отличие от тупого копирования файлов через VSS.

  3. Спасибо автору за интересную статью!

  4. “О виртуализации представлений и приложений — возможно, напишу чуть позже.” Хотелось бы знать когда?

  5. Очень подробно написано. Виртуализацию для себя я только открыл, и уже не терпится начать внедрять у себя на работе. Автор как говоритсяпиши еще.

  6. Теперь немного разобрался в рациональности виртуалки, будемс дальше изучать вопрос. Автору большое спасибо)))