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

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

Я, признаться честно, являюсь технарем «до мозга костей», и модные аббревиатуры вроде 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

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

Компьютеру или ноутбуку не хватает мощности? Необходима комплексная модернизация или простая замена жесткого диска? 

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