Начало работы с контейнерами (часть 1)
- Начало работы с контейнерами (часть 6)
Одной из самых ожидаемых новых возможностей, представленных в Windows Server 2016, являются контейнеры. Однако, несмотря на ажиотаж вокруг контейнеров, контейнеры, кажется, вызывают изрядную путаницу (исходя из того, что я читал на различных досках объявлений в Интернете). В таком случае я хотел воспользоваться возможностью, чтобы объяснить, что такое контейнеры, для чего они используются и для чего не следует использовать контейнеры. Также я покажу вам основы создания контейнеров и работы с ними в Windows Server 2016.
Так что же такое контейнеры? Я могу дать вам определение из трех слов — виртуализация операционной системы.
Когда вы слышите слово «виртуализация», возникает искушение подумать о виртуализации серверов, потому что именно этот тип виртуализации обычно привлекает наибольшее внимание. Тем не менее, существуют и другие типы виртуализации, которые используются уже много лет. Например, на ум приходят виртуализация сети и виртуализация хранилища. Виртуализация операционной системы — это просто еще один тип виртуализации.
В общем смысле виртуализацию можно рассматривать как технологию, которая дает администраторам возможность сделать так, чтобы ресурсы выглядели так, как администратор хотел бы, чтобы они существовали, а не так, как они есть на самом деле. Рассмотрим, например, виртуализацию серверов. У меня есть один конкретный хост-сервер, на котором сейчас работает около дюжины виртуальных машин. Я бы хотел, чтобы у меня была дюжина физических серверов, которые я мог бы использовать для разных целей, но у меня их нет. Тем не менее, виртуализация серверов позволяет мне работать так, как если бы у меня была дюжина разных серверов, даже если эти машины существуют только в киберпространстве.
Давайте используем виртуализированное хранилище в качестве другого примера. Виртуализированные хранилища и виртуализация хранилищ бывают разных форм. Один особенно распространенный тип включает использование тонкой подготовки. Thin provisioning обычно используется с виртуальными машинами. Так же, как физическим компьютерам обычно требуются физические жесткие диски, виртуальным машинам обычно требуются виртуальные жесткие диски. Однако проблема заключается в том, что требования к коллективному хранилищу виртуальных машин организации могут быстро превысить доступную физическую емкость хранилища.
Возьмем, к примеру, то, что я сказал ранее о наличии дюжины виртуальных машин, работающих на одном из моих хост-серверов. Размер виртуального жесткого диска по умолчанию в Hyper-V составляет 127 ГБ. Большинство, если не все ранее упомянутые виртуальные машины, работают с конфигурациями по умолчанию. Это означает, что 12 виртуальных машин, каждая со 127 ГБ хранилища, должны в совокупности потреблять 1524 ГБ пространства. На самом деле мои виртуальные машины занимают гораздо меньше места благодаря тонкой настройке.
Когда Windows создает виртуальный жесткий диск с тонкой подготовкой, на самом деле не имеет значения, насколько большой администратор делает виртуальный жесткий диск. Первоначально виртуальный жесткий диск занимает менее 1 ГБ дискового пространства. Дополнительное пространство на физическом диске используется только при добавлении данных на виртуальный жесткий диск. Цель тонкой подготовки — помочь виртуальным жестким дискам занимать как можно меньше места на физическом диске.
Итак, ранее я сказал, что технологии виртуализации могут дать вам иллюзию наличия ресурсов, которые вы хотели бы иметь. Подумайте, как тонкая подготовка поддерживает это утверждение. Если вы когда-либо мечтали о неограниченном пространстве для хранения, это желание может практически сбыться. Hyper-V позволяет подключать к виртуальной машине большое количество дисков объемом несколько ТБ, даже если на узле недостаточно места на физическом диске для размещения хранилища. Это известно как чрезмерное обязательство. Чрезмерное обязательство становится проблемой только в том случае, если вы пытаетесь записать больше данных, чем физически может вместить базовое оборудование хранения.
Какое отношение все это имеет к контейнерам? Как упоминалось ранее, контейнеры — это просто еще одна форма виртуализации. Как я уже говорил, контейнеры можно рассматривать как виртуализацию операционной системы. Если эта концепция все еще немного туманна, подумайте о контейнерах как о методе виртуализации серверов следующего поколения.
Прямо сейчас я уверен, что есть много людей, которые съеживаются, потому что я только что упомянул контейнеры как форму виртуализации серверов следующего поколения. Прежде чем вы отправите мне гневное электронное письмо, позвольте мне уточнить.
Я уверен, вы знаете, что использование виртуализации серверов дает ряд различных преимуществ. Основное преимущество, вероятно, заключается в том, что виртуализация серверов позволяет более полно использовать серверное оборудование, чем это было бы возможно, если бы сервер выполнял одну рабочую нагрузку. Еще одним преимуществом виртуализации серверов является то, что рабочие нагрузки могут быть изолированы друг от друга. Виртуальная машина действует как граница изоляции, которая может предотвратить конфликты приложений друг с другом, как если бы они работали в общей операционной системе.
Однако, какой бы великолепной ни была виртуализация серверов, она ужасно неэффективна. Чтобы показать вам, что я имею в виду, рассмотрим сервер под управлением Windows Server 2012 R2 Hyper-V. Очевидно, есть одна вещь, которую можно сделать сразу, чтобы сделать сервер более эффективным. Hyper-V можно настроить для работы в составе ядра сервера. Тем не менее, в игру вступают другие, гораздо более серьезные недостатки.
Сам гипервизор можно сделать относительно эффективным. Проблема в виртуальных машинах. В случае сервера Hyper-V под управлением Windows Server 2012 R2 Datacenter Edition можно с уверенностью сказать, что большинство виртуальных машин, вероятно, также работают под управлением операционной системы Windows Server 2012 R2. Конечно, Hyper-V может работать с широким спектром операционных систем, и вполне возможно, что сервер, подобный обсуждаемому в этом примере, может работать под управлением других операционных систем, отличных от Windows, или устаревших операционных систем Windows на своих виртуальных машинах. Тем не менее, есть вероятность, что большинство виртуальных машин работают под управлением Windows Server 2012 R2. Причина, по которой я говорю это, заключается в лицензировании. Сервер Hyper-V под управлением Windows Server 2012 R2 Datacenter Edition имеет лицензию на запуск неограниченного количества виртуальных машин Windows Server 2012 R2.
Итак, представьте, что на этом конкретном сервере есть родительская операционная система и десять виртуальных машин, каждая из которых работает под управлением Windows Server 2012 R2. На сервере работает одиннадцать копий одной и той же операционной системы! Будет одиннадцать копий многих файлов. Будет одиннадцать различных экземпляров некоторых системных процессов, работающих одновременно. Именно это я имею в виду, когда говорю, что виртуализация серверов неэффективна.
Но что, если бы вместо этого вы могли запустить одну гостевую операционную систему или выделенную операционную систему для каждой виртуальной машины, не отказываясь от преимуществ изоляции? Сколько памяти это сэкономит? Насколько сильно сокращение количества гостевых операционных систем повлияет на циклы ЦП и IOPS хранилища? Вот что такое контейнеры.
Контейнеры предназначены для виртуализации операционной системы таким образом, чтобы можно было запускать одну копию операционной системы, сохраняя при этом границы изоляции между вашими рабочими нагрузками.
Вывод
Надеюсь, вы начали понимать, почему контейнеры так важны. В следующей статье этой серии я собираюсь углубиться в анатомию контейнеров Windows Server.
- Начало работы с контейнерами (часть 6)