Главная 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,Новое
    • Автор: Александр Косивченко
    • Дата: Воскресенье 29 Мар 2009

Комментарии

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

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

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

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

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

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

Опубликовать

Я не робот.