Под сервером обычно понимается отдельный (обычно мощный) компьютер, специализированный под выполнение задач по обслуживанию абонентов (предоставление сервисов). Количество таких сервисов, одновременно выполняемых в рамках одного сервера, ограничено сверху вычислительными возможностями оборудования, пропускной способностью канала для запросов клиентов и т. п. На практике количество сервисов на одном сервере обычно больше одного, как из экономических соображений (невыгодно позволять простаивать дорогому серверному оборудованию), так и из технологических (зачастую сервисы бывает удобно аггрегировать на одном узле, т. к. они могут работать взаимосвязанно, например, с одними и теми же данными).
С развитием технологий постоянно нарастающие мощности компьютерного оборудования намного опережают рост запросов к ресурсам со стороны программ. В результате всё выше поднимается верхняя граница по числу возможных сервисов на одном сервере, и все более невыгодно становится держать сервер только для одного сервиса — ресурсы простаивают.
Виртуализация в операционных системах понимается широко и разнообразно. Если пробовать выделить общее, то речь всегда идёт о запуске в той или иной степени полноценной операционной системы (далее ОС), работающей в рамках другой ОС (или в гипервизоре: специализированной ОС, которая только и умеет, что обеспечивать работу других ОС внутри себя). Такую виртуализованную ОС называют чаще всего гостевая ОС (а также виртуальное окружение и др.), а ОС, внутри которой выполняется гостевая, — хост-системой (также аппаратный узел, Hardware Node). Виртуальное окружение, внутри которого выполняется программа, обычно неотличимо для нее от невиртуализованной ОС. Здесь мы не будем подробно рассматривать разные технологии виртуализации, для этого лучше обращаться к специальным источникам1.
В контексте системного администрирования наиболее существенны два свойства любой технологии виртуализации. Первое состоит в том, что виртуализация вводит промежуточный уровень между оборудованием (аппаратным обеспечением) и программным обеспечением. Использование этого уровня даёт администратору возможность гибко управлять распределением аппаратных ресурсов между параллельно выполняющимися программами. Второе — помещение программ в виртуальное окружение довольно надёжно изолирует их от всех прочих программ, исполняющихся на этом же физическом оборудовании вне данного окружения. Тем самым радикально снижается вероятность побочного влияния работы одних программ на работу других, в том числе снижается вероятность атак, построенных на подобных побочных взаимодействиях.
Традиционный подход к размещению сервисов состоит в том, что на одном физическом сервере работает одна операционная система, в рамках которой выполняются несколько системных служб, предоставляющих те или иные сервисы.
У нескольких задач, выполняющихся в рамках одной ОС (иначе говоря, в разделяемой среде), всегда есть возможности для взаимодействия, поскольку ОС именно для организации такого взаимодействия и предназначена. Кроме того, в разделяемой среде задачи совместно пользуются общими интерфейсами (файловая система, структуры ядра...) и в конечном итоге общими аппаратными ресурсами, что открывает дорогу побочным взаимодействиям. В случае независимых сервисов подобное взаимодействие равнозначно помехам и нарушению работы.
В UNIX-системах, при разработке которых многозадачность являлась одним из важнейших приоритетов, уже присутствует комплекс средств для решения задач изоляции и контроля. К подобным средствам относятся, например, системный вызов chroot(), обеспечивающий изоляцию на уровне файловой системы, во FreeBSD существует также технология jail, дополнительно к этому ограничивающая доступ к структурам ядра. В последних версиях ядра Linux реализована поддержка аппаратной паравиртуализации (kvm, применимо в том случае, если ее поддерживает процессор). Однако стандартные средства UNIX-систем не решают всех проблем совместного размещения сервисов.
Путь разрешения обозначенных проблем — использовать средства виртуализации, чтобы исключить возможности побочного взаимодействия и получить дополнительную к средствам ОС точку контроля за потреблением аппаратных ресурсов. Так, в последнее время нормой постепенно становится размещение нескольких сервисов в рамках одного сервера не в одной и той же ОС, а в отдельных виртуальных окружениях. Далее мы будем называть такое виртуальное окружение с работающей в нём системной службой виртуальным контейнером.
С точки зрения задачи виртуализации сервисов не принципиально, какая конкретно технология виртуализации выбрана для создания контейнера. При большой вычислительной нагрузке это вряд ли может быть виртуальная машина, эмулирующая все оборудование компьютера, но вполне может использоваться одна из систем с гипервизором. Для UNIX-систем может быть весьма удобно применять одну из технологий виртуализации на уровне ОС, доводящих средства изоляции и контроля UNIX до уровня, достаточного для организации полноценных виртуальных окружений. К таким технологиям относятся OpenVZ (широко применяемый в ALT Linux) и VServer.
Во многих областях обслуживания абонентов критически важно обеспечивать постоянную работу сервиса, минимизировать простои из-за неполадок или управляться с большим потоком запросов, чтобы они не приводили к нарушению работы сервиса. Системы, обладающие техническими характеристиками для выполнения этих условий, называют системами высокой надёжности (high availability systems). Помещение сервиса в виртуальный контейнер можно использовать для повышения надёжности его работы.
Бывают ситуации, особенно при работе под большой нагрузкой, когда затребованные сервисом ресурсы настолько велики, что могут привести к неработопособности самой операционной системы. Средствами виртуального окружения можно ограничить верхний предел ресурсов системы, выделяемых сервису в рамках виртуального контейнера.
Т. е. технология виртуализации применяется в данном случае как средство контроля ресурсов, потребляемых отдельной задачей, и обеспечивает непревышение этих ресурсов (поскольку задача не имеет прямого доступа к оборудованию). Эту задачу большинство средств виртуализации решает весьма надёжно.
Такой подход повышает надёжность системы, поскольку гарантирует операционную систему от неработоспособности по причине превышения ресурсов со стороны сервиса. Однако этот метод, естественно, не может гарантировать от сбоев самого сервиса, вызванных, например, большим потоком запросов.
Помещение сервиса в виртуальный контейнер позволяет минимизировать время простоя даже в ситуации сбоя виртуального контейнера из-за превышения ресурсов, поскольку потребуется только восстановить виртуальный контекст, что в среднем быстрее, чем перезагрузка всего сервера.
Таким образом, даже в случае размещения на сервере только одного сервиса, оправдано его помещение в виртуальный контейнер.
В ряде случаев необходимо предоставить клиентам сервиса некоторые гарантии качества обслуживанияш (QoS, quality of service). Примером такой ситуации может служить телефонный разговор: после соединения клиент получает гарантию, что во время разговора не закончатся ресурсы канала связи и разговор не прервётся. Другой пример, уже из области системного администрирования: весьма желательно гарантировать, что даже при максимальной нагрузке на сервере (в том числе в ситуации DoS-атак), у сервиса SSH будет достаточно ресурсов, чтобы обеспечить удалённый вход на сервер системного администратора, который мог бы принять срочные меры.
Чтобы обеспечить качество обслуживания для сервиса, администратору необходимо гарантировать достаточный объем аппаратных ресурсов для этого сервиса, т. е. исключить ситуации сбоя сервиса из-за физической нехватки ресурсов в системе.
И здесь можно использовать виртуализацию сервисов. Если сервис работает в виртуальном контейнере, то гарантия минимального уровня ресурсов сводится к тому, что процессы, выполняемые вне данного контейнера, в сумме не затребуют больше ресурсов, чем разность между объемом ресурсов системы и ресурсами данного контейнера.
Так, если в системе параллельно выполняется несколько сервисов, каждый из которых помещён в отдельном виртуальном контейнере, то задача администратора — ограничить ресурсы каждого контейнера таким образом, чтобы сумма выделенных им ресурсов не превышала всех ресурсов системы, и при этом выделенные каждому сервису ресурсы были достаточны для его нормальной работы.
В случае, если сервисы не помещены в виртуальные контейнеры, добиться гарантированной нижней границы доступных ресурсов можно только в том случае, если на одном физическом сервере выполняется только один сервис. В противном случае работает правило «кто первый встал, того и тапки», т. е. любой из сервисов может в какой-то момент занять большой объём свободных ресурсов, так что оставшегося не хватит другому сервису для нормальной работы.
Иначе говоря, в разделяемой среде невозможно гарантировать отдельному сервису нижнюю границу доступных ресурсов, и, следовательно, невозможно дать гарантии клиентам по качеству обслуживания.
В случае виртуализованного сервиса, взломщик может получить доступ только в рамках виртуального контейнера, так что даже если на сервере параллельно выполняются другие сервисы (в других виртуальных контейнерах), то их работе данный инцидент угрожать не будет. Попытки взломщика исчерпать все физические ресурсы приведут только к исчерпанию ресурсов данного контейнера. Таким образом, взломщик не сможет затруднить удалённый доступ администратора на сервер, исчерпав все доступные ресурсы. Кроме того, изнутри контейнера у взломщика нет возможности перезаписать загрузчик сервера и получить какой-либо прямой контроль над оборудованием.
При подобном инциденте администратор может просто целиком уничтожить скомпрометированный виртуальный контекст и восстановить его и данные из резервной копии, не перезагружая сервер и не останавливая работу прочих выполняющихся на нём сервисов.
Из предыдущих разделов становится понятно, что при использовании виртуальных контейнеров на сервере работоспособность как виртуализованных сервисов, так и основной ОС сервера весьма существенно зависит от надёжности работы механизмов ограничения и изоляции, заложенных в технологии виртуализации.
Такие механизмы ограничения могут быть двух родов: аппаратные и программные. Если используется платформа, поддерживающая виртуализацию на аппаратном уровне, то алгоритмы изоляции контекстов реализованы непосредственно в оборудовании, подвести здесь может только ошибка в микросхеме. Во всех остальных технологиях виртуализации механизмы ограничения реализованы так или иначе программно, и, как показывает практика, в программных реализациях ошибки встречаются.
Производители программного обеспечения, выполняющего те или иные серверные функции (т. е. предоставляющие некоторый сервис), могут встраивать в свои продукты собственные средства контроля ресурсов, предоставляющие примерно ту же функциональность, что и ограничение средствами виртуального контейнера. Однако как в любой программной реализации в этих механизмах возможны ошибки, дающие возможность при определённых условиях обходить установленные ограничения.
Однако вероятность ошибок в механизмах ограничения тем выше, чем больше разных механизмов использовано в системе. Поэтому в случае размещения на сервере нескольких виртуальных контейнеров с сервисами правильнее использовать один общий механизм контроля, предоставляемый средством виртуализации. Кроме того, если используется стандартное для дистрибутива средство виртуализации (OpenVZ в случае ALT Linux), то возможные ошибки, критичные для безопасности, будут быстрее обнаружены и исправлены.
При организации сервера с использованием виртуализованных сервисов критически важной точкой для безопасности системы становится интерфейс управления самими виртуальными контейнерами. Доступ к этому интерфейсу должен быть наиболее обстоятельно защищён.
Возможные варианты защиты доступа к интерфейсу управления:
Выше уже говорилось о том, что современное оборудование позволяет одновременно выполнять значительно больше одного сервиса на одном сервере. При использовании некоторых технологий виртуализации вычислительных ресурсов сегодня хватает на организацию множества виртуальных контекстов на сервере, даже с учётом дополнительных вычислительных расходов на виртуализацию. Технологии виртуализации на уровне операционной системы (для UNIX-систем) позволяют одновременно эксплуатировать сотни виртуальных контекстов на одном достаточно мощном сервере.
Типичная сфера применения подобных решений — хостинг-провайдеры: при использовании виртуальных контекстов каждому клиенту можно выдать независимое окружение с правами суперпользователя, предоставив администрирование внутри контекста на его полное усмотрение.
Выгоды от малой и до массовой консолидации сервисов на одном сервере в первую очередь лежат в сфере снижения затрат на приобретение, размещение и обслуживание оборудования. Традиционно подобная консолидация сдерживалась соображениями безопасности и качества обслуживания, которые также обеспечиваются средствами виртуальных контейнеров.
Еще одна неочевидная, но немаловажная выгода, представляемая помещением сервисов в виртуальные контейнеры происходит от того, что виртуальные контексты, с одной стороны, самодостаточны, а с другой — отчуждаемы от оборудования. Благодаря этому, администратор имеет возможность манипулировать виртуальными контейнерами как целостными объектами, в том числе переносить с одного сервера на другой. Так, для большинства технологий виртуализации есть средства для «заморозки» контейнера в текущем состоянии, с возможностью последующей разморозки, в том числе на другом сервере, при том что выполняемые внутри контейнера процессы даже не заметят происшедшей перемены.
Такие возможности позволяют даже в процессе работы мигрировать виртуализованные сервисы, например, по разным узлам сети, гибко перераспределяя вычислительную нагрузку, в том числе среди узлов кластера. Кроме того, можно уничтожить ставший ненужным виртуальный контейнер, при этом не возникнет необходимости продавать высвободившийся сервер: просто остальные контейнеры смогут разделить высвобившиеся мощности.
1См. например хорошую вводную статью (на английском языке) http://www-128.ibm.com/developerworks/linux/library/l-linuxvirt/?ca=dgr-lnxw01Virtual-Linux.