Зачем же нужна виртуализация?

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

Я, признаться честно, являюсь технарем «до мозга костей», и модные аббревиатуры вроде 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);
  • Простота администрирования: легкость перемещения виртуальных машин с одного физического сервера на другой, быстрота развертывания новой машины из эталонного образа, простота создания резервной копии и восстановления из нее, использование «моментальных снимков».

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

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

Источник: microsoft

Вы можете задать вопрос по статье специалисту.

Мы поможем правильно эксплуатировать ПО и оборудование.

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