Использование Solaris Zones

Антон Павленко

ВиртуализацияВиртуальный сервер не привязан к конкретному “железу”

• высокая доступность• динамическое увеличение

ресурсов• простота миграции• легкость распространения

КонсолидацияОбъединение нескольких виртуальных серверов в рамках одного сервера

• повышение утилизации ресурсов

• рост производительности системы

• значительная экономия

Почему Solaris Zones?

Что такое Solaris Zones?• виртуальное окружение,

которое выглядит и управляется как обыкновенный Solaris

• зоны работают на базе одного ядра Solaris с ограниченными привилегиями

• минимальные накладные расходы

Типы зонКаждый образ Solaris сам по себе

уже зона.Глобальная зона управляет

ресурсами сервера, позволяет распределять ресурсы локальным зонам, администрировать сами зоны.

Локальные зоны :• Sparse : наследует ряд файлов от

глобальной зоны• Whole-root : полная копия всех

файлов с возможностью модификации

Одно приложение одна зона?Не стоит применять когда приложения используют shared memory.Во всех остальных случаях стоит • изоляция приложений

– позволяет запускать на одном сервере даже конфликтующие между собой приложения– сбой одного приложения не приведет сбою или к остановке остальных

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

• унификация– виртуализация IP позволяет приложению в каждой зоне использовать стандартные

порты

Существующая схема• Производительность

оборудования постоянно растёт• Часто утилизация серверов ниже

50%• Значительная часть общего

времени отклика системы составляет взаимодействие подсистем

• Неоднозначность планирования загрузки ресурсов для расширения

Всё в одном• консолидация позволяет

значительно снизить накладные расходы на передачу данных• Все сетевое взаимодействие между зонами

реализуется на уровне ядра Solaris

• уменьшить общее количество компонент• И унифицировать оставшиеся

• повысить безопасность

Всё в одном• консолидация позволяет

значительно снизить накладные расходы на передачу данных• Все сетевое взаимодействие между зонами

реализуется на уровне ядра Solaris

• уменьшить общее количество компонент• И унифицировать оставшиеся

• повысить безопасность• Подключать данные только для чтения• Не делать доступными по сети внутренние службы

Мало одного сервера?• zfs clone позволяет легко

дублировать существующие зоныzoneadm -z zone1 clone template real 0.42user 0.06sys 0.09

• zfs send/recv позволяет легко переносить зоны между серверамиzfs send zones/webfrontend1@today | ssh server2 zfs recv zones/webfrontend@today

Мало одного сервера?• централизованное

хранилище снимает проблемы с гранулярностью репликации

• повышает доступность серверов- время поднятия зоны на другом сервере минимально

• упрощает масштабируемость

Простота тестирования и внесения изменений• при возникновении проблемы

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

• легкость тестирования при внесении изменений

• простота отката в случае возникновения проблем

• быстрое распостранение внесенных изменений

Управление ресурсамиПо умолчанию все зоны видят все процессора

– а также все утилиты ( vmstat, prstat ) считают % на основе всех CPU

Два различных способа разделения ресурсов процессора :– FSS (Fair Share Scheduling )– CPU pool

Два различных способа подключения сети– Exclusive : в зону передается целиком интерфейс. Сеть настраивается на уровне

зоны– Shared : параметры сети задаются в конфигурации зоны.

Возможность разделения памяти между зонами

CPU pool• гарантированное кол-во CPU• CPU жестко закреплены за зоной

– если зона не использует часть выделенных CPU то они будут простаивать

• утилиты ( vmstat, prstat ) знают о pool’ах и показывают загрузку именно pool’а

• неравномерная загрузка процессоров в рамках одного сервера

Dynamic CPU pool• можно задавать не точное кол-

во процессоров а диапазон– в случае высокой загрузки процессоры будут

перераспределены автоматически в рамках выбранных диапазонов

• различные варианты настроек– wt-load – Locality (tight, loose, none )– Utilization ( < > ~ )

poolcfg -dc ’modify pset large (string pset.poold.objectives="utilization<75")’

• детальное логирование и мониторинг

Dynamic CPU pool• можно задавать не точное кол-

во процессоров а диапазон– в случае высокой загрузки процессоры будут

перераспределены автоматически в рамках выбранных диапазонов

• различные варианты настроек– wt-load – Locality (tight, loose, none )– Utilization ( < > ~ )

poolcfg -dc ’modify pset large (string pset.poold.objectives="utilization<75")’

• детальное логирование и мониторинг

Fair Share Scheduling• тип scheduler’а• контролирует выделение CPU

на основе долей• загрузка всех CPU равномерна• в случае если зона не

использует выделенные ей ресурсы, их могут использовать другие

• зоне доступны все CPU

Fair Share Scheduling

• возможно online перераспределение долей

• при добавлении новой зоны все доли необходимо пересчитывать

• нет простого способа мониторинга и анализа загрузки

Выводы• по возможности используйте sparse зоны

– совместное использование компонент– минимальные накладные расходы на память ( shared libs, бинарные файлы )

• используйте whole root зоны только когда это действительно необходимо– необходимость постоянно писать в /usr– тестирование патчевания основных компонент

• группируйте приложения в зоны– при возможности использования shared memory

• при разграничении прав доступа• используйте LOFS для предоставления общих данных зонам

Выводы• используйте все возможности ZFS

– клонирование для deployment’а и тестирования– snapshot’ы для резервного копирования и анализа изменений– компрессию для экономии дискового пространства

• в зависимости от требований используйте либо FSS либо CPU pools• FSS лучше утилизирует CPU но затрудняет анализ• на основе dynamic pool легко строить (само)масштабируемые

системы• по возможности ограничение по памяти лучше не использовать

Спасибо!