2. Виртуализация Виртуальный сервер не привязан к конкретному “железу” высокая доступность динамическое увеличение ресурсов простота миграции легкость распространения
3. Консолидация Объединение нескольких виртуальных серверов в рамках одного сервера повышение утилизации ресурсов рост производительности системы значительная экономия
6. Что такое Solaris Zones? виртуальное окружение, которое выглядит и управляется как обыкновенный Solaris зоны работают на базе одного ядра Solaris с ограниченными привилегиями минимальные накладные расходы
7. Типы зон Каждый образ Solaris сам по себе уже зона. Глобальная зона управляет ресурсами сервера, позволяет распределять ресурсы локальным зонам, администрировать сами зоны. Локальные зоны : Sparse : наследует ряд файлов от глобальной зоны Whole-root: полная копия всех файлов с возможностью модификации
8. Одно приложение одна зона? Не стоит применять когда приложения используют shared memory. Во всех остальных случаях стоит изоляция приложений позволяет запускать на одном сервере даже конфликтующие между собой приложения сбой одного приложения не приведет сбою или к остановке остальных безопасность в случае проблем с одним приложением это никак не скажется на других возможно дополнительно защитить данные от изменений унификация виртуализация IP позволяет приложению в каждой зоне использовать стандартные порты
9. Существующая схема Производительность оборудования постоянно растёт Часто утилизация серверов ниже 50% Значительная часть общего времени отклика системы составляет взаимодействие подсистем Неоднозначность планирования загрузки ресурсов для расширения
26. CPU pool гарантированное кол-во CPU CPU жестко закреплены за зоной если зона не использует часть выделенных CPU то они будут простаивать утилиты ( vmstat, prstat ) знают о pool’ах и показывают загрузку именно pool’а неравномерная загрузка процессоров в рамках одного сервера
27. Dynamic CPU pool можно задавать не точное кол-во процессоров а диапазон в случае высокой загрузки процессоры будут перераспределены автоматически в рамках выбранных диапазонов различные варианты настроек wt-load Locality (tight, loose, none ) Utilization ( < > ~ ) poolcfg -dc ’modify pset large (string pset.poold.objectives="utilization<75")’ детальное логирование и мониторинг
28. Dynamic CPU pool можно задавать не точное кол-во процессоров а диапазон в случае высокой загрузки процессоры будут перераспределены автоматически в рамках выбранных диапазонов различные варианты настроек wt-load Locality (tight, loose, none ) Utilization ( < > ~ ) poolcfg -dc ’modify pset large (string pset.poold.objectives="utilization<75")’ детальное логирование и мониторинг
29. Fair Share Scheduling тип scheduler’а контролирует выделение CPU на основе долей загрузка всех CPU равномерна в случае если зона не использует выделенные ей ресурсы, их могут использовать другие зоне доступны все CPU
30. Fair Share Scheduling возможно online перераспределение долей при добавлении новой зоны все доли необходимо пересчитывать нет простого способа мониторинга и анализа загрузки
31.
32. Выводы по возможности используйте sparse зоны совместное использование компонент минимальные накладные расходы на память ( shared libs, бинарные файлы ) используйте whole root зоны только когда это действительно необходимо необходимость постоянно писать в /usr тестирование патчевания основных компонент группируйте приложения в зоны при возможности использования shared memory при разграничении прав доступа используйте LOFS для предоставления общих данных зонам
33. Выводы используйте все возможности ZFS клонирование для deployment’а и тестирования snapshot’ы для резервного копирования и анализа изменений компрессию для экономии дискового пространства в зависимости от требований используйте либо FSS либо CPU pools FSS лучше утилизирует CPU но затрудняет анализ на основе dynamic pool легко строить (само)масштабируемые системы по возможности ограничение по памяти лучше не использовать
