Эффективность дедупликации хранилища на примере StarWind iSCSI SAN

Статья опубликована в журнале «Системный Администратор»

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

Во времена стремительного развития технологий виртуализации достаточно широко рассматриваются вопросы эффективности использования ресурсов выделяемых под нужды виртуальных серверов и рабочих станций. Одним из важных направлений на сегодняшний день является оптимизация использования дискового пространства на системах хранения занимаемого виртуальными машинами (далее ВМ). Сегодня уже существуют хорошо зарекомендовавшие форматы «тонких дисков» (Thin provisioning) которые увеличиваются в объеме по мере заполнения данными. При виртуализации рабочих станций применяется технология «золотого образа» позволяющая использовать один единственный виртуальный диск как основу для множества ВМ, сохраняя для каждой лишь отличия от «золотого» образа. Но особой популярностью в последнее время пользуется технология дедупликации данных. Сама по себе технология не молода[1], но на сцену виртуализации вышла не так давно, хорошо зарекомендовав себя в системах резервного копирования. Дедупликация работает на уровне блоков данных абсолютно не взирая на типы файлов и их содержимое. Поток данных, разделяется на блоки определенного размера, после чего выполняется их сравнение с уже записанными блоками. Сравнение блоков выполняется специальными алгоритмами исключающими коллизии стандартных-хеш функций, способных привести в последствии к разрушению данных. Фактически, на диск записываются только уникальные блоки данных, а там где они повторяются просто создаются на них ссылки.

Читать дальше

CloudStack 4. Создание и запуск виртуальных машин

После того как выполнена установка и базовая настройка облака под управлением CloudStack самое время посмотреть на него в работе запустив парочку другую виртуальных машин(далее ВМ) и понаблюдать за их работой.

CloudStack, это высокоуровневая система управления гетерогенной виртуальной инфраструктурой, которая разработана для удобного управления средами с большим количеством различных гипервизоров, предоставляя удобные механизмы управления.  Архитектура CloudSack, изначально сделана многоуровневой и масштабируемой по этому даже для запуска всего одной ВМ необходимо иметь сконфигурированную Зону(Zone), Стойку(Pod), Кластер(Cluster), хотя бы один Хост(Host) в кластере а так же по одному Первичному(Primary) и Вторичному(Secondary) хранилищу.

Перед тем как будет создан и запущен первый instace(ВМ в терминологии CloudStack), стоит отметить, что если все было сделано как в предыдущей статье, то в вашем облаке уже работает несколько ВМ. Эти ВМ-призраки которые не отображаются в разделе Instance являются служебными и увидеть их можно в разделе Infrastructure пункт System VMs. Скорей всего, будут доступны две ВМ тип(Type) у которых будет Console Proxy VM и Secondary Storage VM. Эти служебные ВМ разворачиваются CloudStack’ом из служебного шаблона SystemVM Template(доступен в разделе Templates) по мере необходимости для выполнения тех или иных служебных и фоновых задач. Например ВМ Secondary Storage VM обслуживает все операции связанные с Вторичным хранилищем(Secondary storage) и непосредственно участвует при загрузки новых шаблонов и ISO-образов в CloudStack. Что либо делать с системными ВМ не рекомендуется. CloudStack сам принимает решение когда какая то из ВМ не нужна или наоборот необходимо несколько. Убедитесь, что Secondary Storage VM работает(в сотоянии Running) т. к. без нее загрузка шаблонов и ISO-образов будет не возможной!

Читать дальше

XenServer 5.6. Распределение ресурсов CPU

Статья была написана 14 мая 2011 г. Перенесена из старого блога.

По умолчанию, все вЦП(vCPU) работают(как процессы) на всех физических ЦП хоста и имеют одинаковый приоритет между собой. В такой ситуации ресурсы физических ЦП(процессорное время) равномерно распределяются между всеми вЦП. А в случае необходимости любая из ВМ может получить все ресурсы физических ЦП(вне зависимости от количества вЦП), а остальные ВМ будут ждать когда прожорливая ВМ «закончит».
Для избежания подобных ситуаций, в XenServer реализовано несколько техник разграниченичения ресурсов физических ЦП между вЦП или попросту между ВМ.

В графическом интерфейсе XenCenter доступен только один из возможных вариантов — приоритеты вЦП (Рис №1). Данная техника позволят указать приоритет вЦП конкретной ВМ относительно остальных вЦП используемых в других ВМ. Это означает, что при возникновении борьбы за ресурсы физического ЦП, победит та ВМ у которой вЦП имеют наивысший приоритет. В случае же простоя физических ЦП, приоритеты не работают, и любая ВМ даже с низким приоритетом вЦП сможет получить нужные ей ресурсы.

Читать дальше