Исходная задача

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

Требования к системе

• Примерное необходимое количество узлов - 64
• Каждый узел должен иметь доступ в 4 подсети - "публичную", для удалённого доступа к узлу, и "свою" и двух ближайших "соседей", для выполнения заданий
• Студентам должен быть предоставлен доступ с правами суперпользователя
• Должен существовать простой способ вернуть узлы в исходное состояние
• Узел должен обеспечивать производительность, достаточную для компиляции таких программных продуктов как apache httpd и nginx
• Узлы должны быть максимально изолированны друг от друга

Имеющиеся техническое обеспечение

Два сервера Sun Fire T2000 с процессором UltraSPARC T1 1GHz, один из которых имеет 16Gb оперативной памяти, второй - 32Gb.

Рассмотренные варианты решения

Так как предоставление в качестве узлов физических серверов не подходит хотя бы потому, что физические сервера отсутствуют в необходимом количестве, естественным образом выбор пал на использование виртуализации.

Использование популярных решений как VMware vSphere, XEN, Oracle VirtualBox в данном случае невозможно потому, что все они ориентированы на использование архитектуры x86. Поэтому пришлось обратить внимание на менее известные решения.

Вариант 1: Использование LDom

Имеющиеся сервера имеют встроеннуй гипервизор, позволяющий использовать LDom (Logical Domain). Данная технология позволяет на физическом сервере создать количество LDom-ов, равное количеству потоков, поддерживаемых процессором.

Наиболее очевидным преимуществом данного подхода является возможность предоставить полностью самостоятельный экземпляр операционной системы, который студент теоретически может даже переустановить.

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

Но наиболее существенным ограничением в использовании LDom является количество потоков, поддерживаемых процессором T1. Имеющиеся процессоры имеют только 16 потоков, и на двух физических серверах, с учётом необходимости создания управляющего домена, можно создать только 30 узлов, что является недостаточным.

Вариант 2: Использование FreeBSD Jail

Так как в учебной процессе уже используется ОС Solaris, появилось объяснимое желание познакомить студентов с чем-то еще из мира unix. Чем-то не являющимся linux-ом. Учитывая наличие в FreeBSD поддержки T2000, и мои тёплые чувства к этой операционной системе, был рассмотрен вариант с использованием jail, поддержка которых появилась еще в FreeBSD 4.0.

Использование FreeBSD и jail имеет несколько заметных преимуществ перед Solaris с его containers:

• сама операционная система FreeBSD является менее ресурсоёмкой

• в jail можно запустить только один процесс, например, sshd, которого будет достаточно для обеспечения возможности удалённой работы с jail-ом

• администратор сам может определить какие именно утилиты необходимо положить в jail, а теоретически в jail может вообще не быть ни одного исполняемого файла

Но, к сожалению, в jail даже суперпользователь не может менять настройки сетевых интерфейсов и маршрутизацию, что нас совершенно не устраивает. При правильном использовании VIMAGE теоретически это возможно. Но, видимо, об этом будет отдельная статья. Правда всё равно остаются проблемы с предоставлением пользователям доступа в выделенные им jail-ы, но это тоже решаемо.

Вариант 3: Использование Solaris 10 Containers

Пришла пора рассмотреть использование Solaris Containers.

Исходя из наличия в используемой инфракструктуре систем под управлением Solaris 10, начнём рассмотрение с использования зон в Solaris 10.

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

Зоны в Solaris 10 поддерживают так называемые sparse зоны, для которых устанавливается минимальное количество файлов, а (по умолчанию) каталоги /usr и /var монтируются из глобальной зоны, что позволяет существенно уменьшить объём необходимого дискового пространства.

Возможность изменения настроек сетевых интерфейсов в зонах, в отличие от jail, есть, но для этого необходимо включить exclusive режим работы с IP интерфейсами. При этом зоне предоставляется физический интерфейс или его привязка к определённому VLAN.

Для предоставления зонам доступа в лабовые подсети потребовалось бы подключить все 4 интерфейса серверов к коммутатору, заняв в нём суммарно 8 портов, и создав на 3-х из них по 32 тэгированных интерфейса. Но предоставить всем доступ в общий VLAN уже затруднительно, так как для этого необходимо количество физических интерфейсов, равного количествую конфигурируемых зон (включая глобальную).

Вариант 4: Использование Solaris 11 Containers

С точки зрения решаемой задачи, одним из отличий Solaris 11 от Solaris 10, является появление в нём crossbow, который позволяет создавать виртуальные коммутаторы и виртуальные сетевые интерфейсы.

Таким образом с использованием Solaris 11 удалось обойтись одним физическим подключением от сервера к коммутатору, создав на одном физическом интерфейсе необходимое количество виртуальных сетевых интерфейсов для каждого VLAN.

Одним из ограниченией зон в Solaris 11 является отсутствие возможности создания sparse зон, соответственно каждая зона должна иметь свою файловую систему со своим набором пакетов. Минимизировать потери дискового пространства удалось используя существующую в ZFS возможность клонирования файловых систем. Т.е. фактически была установлена одна зона, после установки был сделан снимок файловой системы, из которого создано необходимое количество клонов. Также по окончанию курса или при возникновения проблем с зоной использование снимков позволяет быстро вернуть зону в её исходное состояние.

При настройке зон в Solaris 11 я столкнулся одной неожиданной проблемой: сервис в Solaris, который запускает зоны, делает это параллельно. Вычислительные мощности на T2000 достаточно ограничены, и на ненагруженной системе на загрузку каждой зоны необходимо чуть менее 2-х минут. А попытка сервиса загрузить в параллель 32 зоны приводит к довольно неприятной картине:

# uptime
12:12pm up 8 min(s), 1 user, load average: 65.60, 42.49, 19.64

Из-за перегруженности CPU некоторые сервисы в зонах не успевают запуститься за указанное время  и зоны не могут работать полноценно.

Для решения этой проблемы пришлось отключить автозагрузку зон и писать скрипт, который запускает зоны последовательно, не допуская такой ситуации.

Таким образом и эта проблема была решена, с тем ограничением, что после перезагрузки сервера на запуск всех зон требуется около 50минут.

UPD1: Фактически количество требуемых узлов оказалось немного больше, из-за чего было решено удвоить количество зон на каждом из серверов. В результате на сервере с 16Гб памяти удалось запустить 64 зоны и при этом даже осталось 2.5Гб свободной физической оперативной памяти.

UPD2: Еще одним преимуществом зон в Solaris 11 по сравнению с Solaris 10 можно назвать наличие возможности с помощью RBAC разрешить пользователю доступ к конкретному узлу.

UPD3: При использовании VIMAGE в FreeBSD всё не так плохо, но окончательное решение будет оформлено в виде отдельной статьи.

UPD4: Всё таки с VIMAGE в FreeBSD всё плохо и количество паник оказалось слишком большим.