Раз уж мы говорим о виртуализации - наверняка у кого-то возникает вполне резонный вопрос: а для чего же это вообще нужно? Оговорюсь, что далее речь пойдет о виртуализации серверов. О виртуализации представлений и приложений - возможно, напишу чуть позже.
Я, признаться честно, являюсь технарем "до мозга костей", и модные аббревиатуры вроде TCO, ROI, etc., которыми очень любят оперировать господа маркетологи - для меня являются "китайской грамотой". Соответственно - буду писать о том, что я вижу как технарь.
Наверняка у многих сисадминов в хозяйстве имеется несколько серверов. И обычно это оправданно: многие задачи рекомендуется разносить по разным серверам. К примеру, Microsoft настоятельно не рекомендует совмещать контроллер домена Active Directory и интернет-шлюз на одном физическом сервере. Это создает серьезную угрозу безопасности: в случае атаки на вашу сеть каких-нибудь хакеров или вирусов - первым примет на себя удар, как Брестская Крепость, интернет-шлюз. В случае, если на нем размещался еще и контроллер домена - существует вероятность, что базы AD будут повреждены, либо, что еще хуже - окажутся в руках хакеров. В первом случае понадобится тратить время на восстановление из бэкапов, во втором - очень высокая вероятность дальнейших и более продуманных атак, с использованием логинов и паролей действующих пользователей сети. Ну или просто попадание e-mail адресов пользователей компании в базы спамеров - тоже приятного мало. Одна старая пословица говорит: "Не клади все яйца в одну корзину".
Соответственно, многие системные администраторы ставят контроллер домена на один физический сервер, а интернет-шлюз - на другой. И это, в принципе - правильно: если гипотетические хакеры атакуют интернет-шлюз, и атака будет успешной - вероятность того, что они проберутся дальше шлюза и получат доступ к другим серверам - много меньше.
Но тут возникает новая проблема: каждый отдельный сервер - стоит денег, причем не малых (если речь идет о брэндовых серверах). Каждый отдельный сервер потребляет электроэнергию, и занимает место на столе либо в стойке. Возможно, кому-то это покажется не особо актуальным, тем не менее - это является важным преимуществом. Особенно, если сервера размещаются в стороннем датацентре, где взымают плату за занимаемые юниты в стойках и энергопотребление строго ограничивается. К тому же, в европейских странах существует некий налог, который напрямую зависит от объемов электроэнергии, потребляемых компанией. Не помню, как этот налог называется - что-то связанное с экологией и выбросом CO2.
Кроме этого, каждое из приложений редко потребляет много системных ресурсов: те же контроллеры доменов и интернет-шлюзы - на них редко загрузка процессора превышает 10%. Использование под каждую такую задачу отдельного сервера выглядит нерационально. Совмещать все на одном сервере - как мы уже выяснили, не правильно с точки зрения безопасности. Где же золотая середина? Как же сделать, чтобы и волки были сыты, и овцы целы (и пастуху - вечная память! :)) Ответ дает как раз технология виртуализации.
Что же такое виртуализация? Виртуализация (а именно - виртуализация серверов) - это технология программной эмуляции аппаратного обеспечения компьютера. Причем, на одной физической машине может быть запущено несколько таких виртуальных "компьютеров". На такие виртуальные машины можно ставить операционную систему и приложения, и работать с ними, как с отдельными физическими машинами. Каждая виртуальная машина использует для своей работы какую-то часть аппаратных ресурсов физической машины. Причем, как правило, объем аппаратных ресурсов, выдаваемых отдельным виртуальным машинам можно регулировать - как жестко (статически), так и динамически. Таким образом, аппаратные ресурсы используются намного более рационально. Простой пример: если у нас есть два приложения, которым для работы необходимо 128Мб оперативной памяти, и которые нельзя устанавливать на один физический сервер, можно:
- Купить два сервера с 128M RAM;
- Купить один сервер с 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);
- Простота администрирования: легкость перемещения виртуальных машин с одного физического сервера на другой, быстрота развертывания новой машины из эталонного образа, простота создания резервной копии и восстановления из нее, использование "моментальных снимков".
Собственно, на этом хотелось бы завершить сей и без того длинный опус. Если я что-то пропустил, либо допустил неточность - просьба отметить в комментариях, будет принято к сведению :)
