Solaris Zones : use cases

751 views

Published on

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
751
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
6
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Solaris Zones : use cases

  1. 1. Использование Solaris Zones<br />Антон Павленко<br />
  2. 2. Виртуализация<br />Виртуальный сервер не привязан к конкретному “железу”<br />высокая доступность<br />динамическое увеличение ресурсов<br />простота миграции<br />легкость распространения<br />
  3. 3. Консолидация<br />Объединение нескольких виртуальных серверов в рамках одного сервера<br />повышение утилизации ресурсов<br />рост производительности системы<br />значительная экономия<br />
  4. 4. Почему Solaris Zones?<br />
  5. 5.
  6. 6. Что такое Solaris Zones?<br />виртуальное окружение, которое выглядит и управляется как обыкновенный Solaris<br />зоны работают на базе одного ядра Solaris с ограниченными привилегиями<br />минимальные накладные расходы<br />
  7. 7. Типы зон<br />Каждый образ Solaris сам по себе уже зона.<br />Глобальная зона управляет ресурсами сервера, позволяет распределять ресурсы локальным зонам, администрировать сами зоны.<br />Локальные зоны :<br />Sparse : наследует ряд файлов от глобальной зоны<br />Whole-root: полная копия всех файлов с возможностью модификации<br />
  8. 8. Одно приложение одна зона?<br />Не стоит применять когда приложения используют shared memory.<br />Во всех остальных случаях стоит <br />изоляция приложений<br />позволяет запускать на одном сервере даже конфликтующие между собой приложения<br />сбой одного приложения не приведет сбою или к остановке остальных<br />безопасность<br />в случае проблем с одним приложением это никак не скажется на других<br />возможно дополнительно защитить данные от изменений<br />унификация<br />виртуализация IP позволяет приложению в каждой зоне использовать стандартные порты<br />
  9. 9. Существующая схема<br />Производительность оборудования постоянно растёт<br />Часто утилизация серверов ниже 50%<br />Значительная часть общего времени отклика системы составляет взаимодействие подсистем<br />Неоднозначность планирования загрузки ресурсов для расширения<br />
  10. 10. Всё в одном<br /><ul><li>консолидация позволяет значительно снизить накладные расходы на передачу данных
  11. 11. Все сетевое взаимодействие между зонами реализуется на уровне ядра Solaris
  12. 12. уменьшить общее количество компонент
  13. 13. И унифицировать оставшиеся
  14. 14. повысить безопасность</li></li></ul><li>Всё в одном<br /><ul><li>консолидация позволяет значительно снизить накладные расходы на передачу данных
  15. 15. Все сетевое взаимодействие между зонами реализуется на уровне ядра Solaris
  16. 16. уменьшить общее количество компонент
  17. 17. И унифицировать оставшиеся
  18. 18. повысить безопасность
  19. 19. Подключать данные только для чтения
  20. 20. Не делать доступными по сети внутренние службы</li></li></ul><li>Мало одного сервера?<br /><ul><li>zfs clone позволяет легко дублировать существующие зоны</li></ul>zoneadm -z zone1 clone template<br />real 0.42<br />user 0.06<br />sys 0.09<br /><ul><li>zfs send/recvпозволяет легко переносить зоны между серверами</li></ul>zfs send zones/webfrontend1@today | ssh server2 zfsrecv zones/webfrontend@today<br />
  21. 21. Мало одного сервера?<br /><ul><li>централизованное хранилище снимает проблемы с гранулярностью репликации
  22. 22. повышает доступность серверов</li></ul>- время поднятия зоны на другом сервере минимально<br /><ul><li>упрощает масштабируемость</li></li></ul><li>Простота тестирования и внесения изменений<br /><ul><li>при возникновении проблемы можно сделать точный слепок, для последующего воспроизведения и анализа
  23. 23. легкость тестирования при внесении изменений
  24. 24. простота отката в случае возникновения проблем
  25. 25. быстрое распостранение внесенных изменений</li></li></ul><li>Управление ресурсами<br />По умолчанию все зоны видят все процессора<br />а также все утилиты ( vmstat, prstat ) считают % на основе всех CPU<br />Два различных способа разделения ресурсов процессора :<br />FSS (Fair Share Scheduling )<br />CPU pool<br />Два различных способа подключения сети<br />Exclusive : в зону передается целиком интерфейс. Сеть настраивается на уровне зоны<br />Shared : параметры сети задаются в конфигурации зоны.<br />Возможность разделения памяти между зонами<br />
  26. 26. CPU pool<br />гарантированное кол-во CPU<br />CPU жестко закреплены за зоной<br />если зона не использует часть выделенных CPU то они будут простаивать<br />утилиты ( vmstat, prstat ) знают о pool’ах и показывают загрузку именно pool’а<br />неравномерная загрузка процессоров в рамках одного сервера<br />
  27. 27. Dynamic CPU pool<br />можно задавать не точное кол-во процессоров а диапазон<br />в случае высокой загрузки процессоры будут перераспределены автоматически в рамках выбранных диапазонов<br />различные варианты настроек<br />wt-load<br />Locality (tight, loose, none )<br />Utilization ( < > ~ )<br />poolcfg -dc ’modify pset large (string pset.poold.objectives="utilization<75")’<br />детальное логирование и мониторинг<br />
  28. 28. Dynamic CPU pool<br />можно задавать не точное кол-во процессоров а диапазон<br />в случае высокой загрузки процессоры будут перераспределены автоматически в рамках выбранных диапазонов<br />различные варианты настроек<br />wt-load<br />Locality (tight, loose, none )<br />Utilization ( < > ~ )<br />poolcfg -dc ’modify pset large (string pset.poold.objectives="utilization<75")’<br />детальное логирование и мониторинг<br />
  29. 29. Fair Share Scheduling<br />тип scheduler’а<br />контролирует выделение CPU на основе долей<br />загрузка всех CPU равномерна<br />в случае если зона не использует выделенные ей ресурсы, их могут использовать другие<br />зоне доступны все CPU<br />
  30. 30. Fair Share Scheduling<br />возможно online перераспределение долей <br />при добавлении новой зоны все доли необходимо пересчитывать<br />нет простого способа мониторинга и анализа загрузки<br />
  31. 31.
  32. 32. Выводы<br />по возможности используйте sparse зоны<br />совместное использование компонент<br />минимальные накладные расходы на память ( shared libs, бинарные файлы )<br />используйте whole root зоны только когда это действительно необходимо<br />необходимость постоянно писать в /usr<br />тестирование патчевания основных компонент<br />группируйте приложения в зоны<br />при возможности использования shared memory<br />при разграничении прав доступа<br />используйте LOFS для предоставления общих данных зонам<br />
  33. 33. Выводы<br />используйте все возможности ZFS<br />клонирование для deployment’а и тестирования<br />snapshot’ы для резервного копирования и анализа изменений<br />компрессию для экономии дискового пространства<br />в зависимости от требований используйте либо FSS либо CPU pools<br />FSS лучше утилизирует CPU но затрудняет анализ<br />на основе dynamic pool легко строить (само)масштабируемые системы<br />по возможности ограничение по памяти лучше не использовать<br />
  34. 34. Спасибо!<br />

×