Использование Solaris Zones презентация

Использование 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.42 user 0.06 sys 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 легко строить (само)масштабируемые системы по возможности ограничение по памяти лучше не использовать

Спасибо!