Бенчмаркинг — это очень обсуждаемая тема в компьютерной индустрии из-за бесчисленного множества методов и подходов. Однако в этом блоге не будут перечислены все эти подходы, а вместо этого будет предоставлено представление о том, как мы проводим сравнительный анализ различных видов хранилищ, доступных в наших решениях для размещенного частного облака.

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

Короткий рассказ

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

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

Инструменты и оркестровка

FIO, vdbench, I / O Meter, (dd!) — это лишь некоторые из широко используемых и проверенных инструментов для тестирования хранилища. Они дают вам обзор чистой производительности для данного типа хранилища. Но что, если вы хотите протестировать всю инфраструктуру от начала до конца? Это может включать 1, 10, 100, 1000 виртуальных машин или более, с несколькими настройками диска / рейда, несколькими размерами дисков, несколькими размерами блоков. И все это с различными типичными рабочими нагрузками, состоящими из определенного процента операций чтения / записи, последовательных или случайных, и выполняемых таким количеством потоков. Вам также нужно будет использовать рабочие нагрузки, соответствующие вашим производственным рабочим нагрузкам. На самом деле комбинации бесконечны.

Имея все это в виду, для нашей первой итерации мы начали использовать HCIbench для автоматизации наших тестов.

Тест гиперконвергентной инфраструктуры

HCibench ( flings.vmware.com/hcibench ) — это бесплатный инструмент автоматизации тестов с открытым исходным кодом. Он определяет себя как «Тест гиперконвергентной инфраструктуры». По сути, это оболочка для автоматизации популярных и проверенных инструментов тестирования производительности с открытым исходным кодом: Vdbench и Fio, упрощающая автоматизацию тестирования в кластере HCI. HCIBench стремится упростить и ускорить тестирование производительности клиентских POC последовательным и контролируемым образом. Этот инструмент полностью автоматизирует сквозной процесс развертывания тестовых виртуальных машин, координации выполнения рабочих нагрузок, агрегирования результатов тестирования, анализа производительности и сбора необходимых данных для устранения неполадок.



HCIbench так же просто установить, как развернуть OVA (Open Virtual Appliance) в вашей инфраструктуре VMware:



После настройки HCIbench просто укажите в браузере адрес https: // IP: 8483, и вы готовы приступить к тестированию:





После того, как вы ввели свои учетные данные vCenter и некоторую дополнительную информацию (центр обработки данных, кластер, сеть, хранилище данных и т. Д.), Вы сможете установить настройки гостевых виртуальных машин:

• Количество виртуальных машин для развертывания
• Количество дисков для каждой ВМ
• Размер диска
• Инструмент тестирования (FIO или vdbench)
• Файл параметров ввода-вывода (подробности см. Ниже)
• Продолжительность
• И более …

Затем HCIbench возьмет на себя все операции по развертыванию / утилизации виртуальных машин и выполнит ваш тест. Результаты доступны в различных формах, от интерфейсов Grafana до файлов Excel или просто текстовых файлов для дальнейшего внешнего анализа…

Файлы параметров рабочей нагрузки, моделирование операций ввода-вывода

Файлы параметров рабочей нагрузки (здесь используются vdbench) лежат в основе всех операций тестирования. Они описывают модель ввода-вывода, которую вы хотите использовать для данной конечной точки хранилища. Доступны проценты чтения / записи, случайные / последовательные, размер блока, потоки и многие другие параметры.

Мы выбрали 3 разных подхода для оценки наших платформ хранения: общие рабочие нагрузки, рабочие нагрузки приложений и производственные рабочие нагрузки.

«Общие» рабочие нагрузки

Под «общими» рабочими нагрузками мы понимаем все рабочие нагрузки, которые выглядят как «ТОЛЬКО СЛУЧАЙНОЕ ЧТЕНИЕ» или «ТОЛЬКО ПОСЛЕДОВАТЕЛЬНЫЕ ЗАПИСИ». Они позволяют нам проверить, как тип хранилища реагирует на линейные случаи и как он работает с «крайними» случаями.



Пример «универсального» файла параметров рабочей нагрузки vdbench

root@photon-HCIBench [ /opt/automation/vdbench-param-files ]# cat 
GENERIC-ONLY-READS-RANDOM-16K-vdb-1vmdk-80ws-16k-100rdpct-100randompct-4threads
*SD:    Storage Definition
*WD:    Workload Definition
*RD:    Run Definitionsd=sd1,
        lun=/dev/sda,openflags=o_direct,
        hitarea=0,range=(0,80),
        threads=4,
        wd=wd1,
        sd=sd1,
        rd=run1,
        xfersize=16k,
        rdpct=100,
        seekpct=100,
        iorate=max,
        elapsed=120,
        interval=1

«Приложения»

Под «прикладными» рабочими нагрузками мы понимаем рабочие нагрузки, которые соответствуют типичным производственным сценариям использования, таким как «РАБОЧАЯ ЗАГРУЗКА БАЗЫ ДАННЫХ», «РАБОЧАЯ ЗАГРУЗКА VDI», «РЕЗЕРВНАЯ РАБОЧАЯ ЗАГРУЗКА» и т. Д. отлично.



Пример файла параметров рабочей нагрузки vdbench «Приложение»

root@photon-HCIBench [ /opt/automation/vdbench-param-files ]# cat 
OLTP-SQL-Oracle-Exchange-vdb-1vmdk-80ws-16k-100random-70rdpct-4threads
*SD:    Storage Definition
*WD:    Workload Definition
*RD:    Run Definitionsd=sd1,
        lun=/dev/sda,
        openflags=o_direct,
        hitarea=0,range=(0,80),
        threads=4wd=wd1,
        sd=(sd1),
        xfersize=16k,
        rdpct=70,
        seekpct=100,
        rd=run1,
        wd=wd1,
        iorate=max,
        elapsed=120,
        interval=1

«Производственные» нагрузки.

Наконец, еще один подход, над которым мы работаем, — это возможность «записывать» производственную рабочую нагрузку и «воспроизводить» ее на другой конечной точке хранилища, чтобы оценить, как целевое хранилище работает с вашей производственной рабочей нагрузкой,  без  необходимости запускать на нем реальное производство. Хитрость здесь в том, чтобы использовать сочетание 3 инструментов: blktrace, btrecord и btreplay, чтобы отслеживать и отслеживать вызовы ввода-вывода низкого уровня и иметь возможность воспроизвести эти следы на другой платформе хранения. 

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

Индустриализация HCIbench работает с планировщиком Rundeck

Как мы видели, за несколько щелчков мышью мы можем определить и запустить тестовый сценарий для конкретной рабочей нагрузки. Развертывание и повторное использование тестовых виртуальных машин полностью автоматизировано. Что, если в следующий раз мы захотим повторить несколько сценариев? Например, в рамках общей проверки новой платформы хранения? На этом этапе мы начали использовать Rundeck ( www.rundeck.com), бесплатный планировщик автоматизации Runbook с открытым исходным кодом, перед HCIbench. Идея состоит в том, чтобы иметь возможность создавать полные коллекции сценариев тестов.



Первым шагом было понять, как HCIbench работает под капотом, чтобы мы могли управлять им через планировщик Rundeck. HCIbench разработан для использования через веб-интерфейс, но все его механизмы выполняются с помощью чистых и отдельных скриптов, таких как start / stop / kill. Все настройки тестов хранятся в чистом плоском файле конфигурации, который легко преобразовать в шаблон…

Создание шаблона файла конфигурации HCIbench

root@photon-HCIBench [ /opt/automation/conf ]# cat template.yaml
vc: '<VCENTER_HOSTIP>'
vc_username: '<USERNAME>'
vc_password: '<PASSWORD>'
datacenter_name: '<DATACENTER>'
cluster_name: '<CLUSTER>'
number_vm: '<NUMBERVM>'
testing_duration: '<DURATION>'
datastore_name:- '<DATASTORE>'
output_path: '<OUTPUT_PATH>'
...

Скамья «корневая работа»

Задание rundeck состоит из последовательности шагов, которые будут выполняться для определенного списка узлов. В нашем контексте узлы — это виртуальные машины, на которых работает HCIbench.

То, что мы называем стендовым «корневым заданием», — это задание rundeck, которое является основной точкой входа в стенд. Его общая роль заключается в том, чтобы вызывать другие рабочие места и запускать один конкретный стенд.

Опции (параметры) этого задания — это все элементы из шаблона конфигурации HCIbench (см. Выше).





Рабочий процесс для этого задания следующий:
— Параметры задания синтаксического анализа
— Подключение SSH к виртуальной машине HCIbench
- Заполнение шаблона конфигурации соответствующими параметрами задания
— Запуск HCIbench 

Скамейка

Во-вторых, у нас есть «скамейки запасные». С помощью rundeck API мы создали задания для каждой рабочей нагрузки, чтобы иметь возможность запускать стенды индивидуально или в группе по мере необходимости. Каждое из этих «стендовых заданий» вызывает описанное выше «корневое задание» с соответствующими параметрами стендового анализа.

«Супер» вакансии

Наконец-то у нас есть «Супер вакансии». Это коллекции заданий, их рабочие процессы — это серии вызовов стендовых заданий. Мы используем механизм каскадных опций для передачи опций через задания. В приведенном ниже примере мы тестируем кластер vSAN через полную панель моделей ввода-вывода.



Еще одна интересная особенность использования Rundeck в качестве планировщика HCIbench — это возможность хранить все журналы с виртуальных машин HCIbench и время каждого теста в одном месте. Таким образом, можно легко просматривать и искать по всем нашим тестам или ориентироваться на конкретное поведение, показанное на графике.

Результаты и варианты использования

vSAN
Интеграция vSAN в наш продукт Hosted Private Cloud была типичным эталонным проектом, в котором нам нужно было не только проверить, как вся платформа работает в каждой области, но и уточнить дизайн самой платформы. С одной стороны, мы оценили дизайн оборудования с несколькими ссылками на диски, а с другой стороны, мы улучшили дизайн программного обеспечения, оценив различные группы дисков vSAN и конфигурации кеша.

Влияние нового ядра на массивы хранения

Еще один интересный случай использования — это оценка влияния нового ядра на массивы хранения на базе OmniOS ( www.omniosce.org). OmniOS — это бесплатная операционная система с открытым исходным кодом, основанная на OpenSolaris, которая объединяет некоторые замечательные технологии, такие как ZFS, DTrace, Crossbow, SMF, Bhyve, KVM и поддержку зон Linux. Этот случай показывает не только немного лучшие характеристики, но и значительное улучшение обработки операций ввода-вывода.

Действительно, среди множества различных тестов новое ядро ​​(r151022) показывает гораздо более стабильные и линейные операции ввода-вывода. Этот стенд также подтверждает несколько исправлений ZFS / NFS, которые были включены в это ядро, которые устраняют проблемы с задержкой во время отправки / получения снимка ZFS.



Индустриализация наших тестов позволила нам отслеживать производительность нашего хранилища. Прежде всего, поскольку мы создавали их для наших пользователей, мы согласны с тем, что получат наши клиенты. Кроме того, тесты дают нам представление об устранении проблем с хранением, которые очень специфичны и / или видны только с виртуальных машин. Мы планируем расширить это, чтобы мы могли проверить, как работает вычислительная сторона (CPU / RAM /…). Наконец, теперь мы сосредоточены на функции записи / воспроизведения рабочей нагрузки, позволяющей нашим пользователям прогнозировать, как их производственная рабочая нагрузка будет работать на платформах «XYZ», без необходимости фактически запускать на ней свою производственную среду. Мы подробно расскажем об этом в следующих статьях блога, следите за обновлениями!

При обсуждении концепций DevOps и Infrastructure-as-a-Code быстро всплывают инструменты, разработанные HashiCorp. С Terraform HashiCorp предлагает простой способ автоматизации подготовки инфраструктуры как в общедоступных облаках, так и в локальной среде. Terraform имеет долгую историю развертывания и управления ресурсами публичного облака OVH. Например, вы можете найти полное руководство на GitHub. В этой статье мы сосредоточимся на использовании Terraform для взаимодействия с другим решением OVH: частным облаком.



Частное облако позволяет заказчикам использовать инфраструктуру VMware vSphere, размещенную и управляемую OVH. Terraform позволяет автоматизировать создание ресурсов и их жизненный цикл. В этой первой статье мы исследуем основные понятия Terraform. Прочитав его, вы сможете написать файл конфигурации Terraform для развертывания и настройки виртуальной машины из шаблона. Во второй статье мы построим этот пример и изменим его так, чтобы он был более общим и мог быть легко адаптирован к вашим потребностям.

Установка

Terraform доступен на веб-сайте HashiCorp практически для всех ОС в виде простого двоичного файла. Просто загрузите его и скопируйте в каталог в PATH вашей операционной системы. Чтобы проверить, что все работает правильно, запустите команду terraform.

$ terraform
Usage: terraform [-version] [-help] <command> [args]

The available commands for execution are listed below.
The most common, useful commands are shown first, followed by
less common or more advanced commands. If you're just getting
started with Terraform, stick with the common commands. For the
other commands, please read the help and docs before usage.

Common commands:
    apply              Builds or changes infrastructure
    console            Interactive console for Terraform interpolations
    destroy            Destroy Terraform-managed infrastructure

Папки и файлы

Как и другие инструменты «Инфраструктура как код», Terraform использует простые файлы для определения целевой конфигурации. Для начала мы создадим каталог и поместим файл с именем main.tf. По умолчанию Terraform будет читать все файлы в рабочем каталоге с .tfрасширением, но для упрощения мы начнем с одного файла. В следующей статье мы увидим, как организовать данные в несколько файлов.

Точно так же, чтобы было легче понять операции Terraform, мы укажем всю необходимую информацию прямо в файлах. Сюда входят имена пользователей, пароли и имена различных ресурсов (vCenter, кластер и т. Д.). Совершенно очевидно, что делать это не рекомендуется для использования Terraform в производстве. Вторая статья также даст возможность улучшить эту часть кода. Но пока давайте будем простыми!

Провайдеры

Провайдеры позволяют указать, как Terraform будет взаимодействовать с внешним миром. В нашем примере провайдер vSphere будет отвечать за подключение к vCenter вашего частного облака. Мы декларируем поставщика следующим образом:

provider "vsphere" {
    user = "admin"
    password = "MyAwesomePassword"
    vsphere_server = "pcc-XXX-XXX-XXX-XXX.ovh.com"
}

Здесь мы видим, что Terraform использует свой собственный способ структурирования данных (также можно записать все в JSON, чтобы облегчить автоматическое создание файлов! ). Данные сгруппированы в блоки (здесь блок с именем vsphere, который относится к типу провайдера ), а данные, относящиеся к блоку, представлены в форме ключей / значений.

Данные

Теперь, когда Terraform может подключаться к vCenter, нам нужно получить информацию об инфраструктуре vSphere. Поскольку мы хотим развернуть виртуальную машину, нам нужно знать центр обработки данных, кластер, шаблон и т. Д. И где мы собираемся его создать. Для этого мы будем использовать блоки типа данных:

data "vsphere_datacenter" "dc" {
  name = "pcc-XXX-XXX-XXX-XXX_datacenter3113"
}

data "vsphere_datastore" "datastore" {
  name          = "pcc-001234"
  datacenter_id = "${data.vsphere_datacenter.dc.id}"
}

data "vsphere_virtual_machine" "template" {
  name          = "UBUNTU"
  datacenter_id = "${data.vsphere_datacenter.dc.id}"
}

В приведенном выше примере, мы пытаемся получить информацию о центре обработки данных с именем pcc-XXX-XXX-XXX-XXX_datacenter3113и получить информацию из хранилища данных с именем pcc-001234и шаблона, имя которого является UBUNTU. Здесь мы видим, что мы используем идентификатор центра обработки данных, чтобы получить информацию об объекте, связанном с ним.

Ресурсы

Ресурсы будут использоваться для создания и / или управления элементами инфраструктуры. В нашем примере мы будем использовать ресурс типа virtual_machine, который, как следует из названия, поможет нам создать виртуальную машину.

resource "vsphere_virtual_machine" "vm" {
  name             = "vm01"
  resource_pool_id = "${data.vsphere_compute_cluster.cluster.resource_pool_id}"
  datastore_id     = "${data.vsphere_datastore.datastore.id}"
  guest_id         = "${data.vsphere_virtual_machine.template.guest_id}"
  scsi_type        = "${data.vsphere_virtual_machine.template.scsi_type}"

  network_interface {
    network_id = "${data.vsphere_network.network.id}"
  }

  disk {
    label = "disk0"
    size  = "${data.vsphere_virtual_machine.template.disks.0.size}"
  }

  clone {
    template_uuid = "${data.vsphere_virtual_machine.template.id}"

    customize {
      linux_options {
        host_name = "vm01"
        domain     = "example.com"
      }

      network_interface {
        ipv4_address = "192.168.1.2"
        ipv4_netmask = 24
      }

      ipv4_gateway    = "192.168.1.254"
      dns_suffix_list = ["example.com"]
      dns_server_list = ["192.168.1.1"]
    }
  }
}

Структура этого ресурса немного сложнее, потому что она состоит из нескольких подблоков. Мы видим, что сначала мы определим имя виртуальной машины. Затем мы предоставляем информацию о его конфигурации (пул ресурсов, хранилище данных и т. Д.). И блоки используются, чтобы определить конфигурацию своих виртуальных устройств. Субблок позволит вам указать, какой шаблон вы хотите использовать для создания виртуальной машины, а также указать информацию о конфигурации операционной системы, установленной на виртуальной машине. Субблок является специфическим для типа ОС, которую вы хотите клонировать. На всех уровнях мы используем информацию, полученную ранее в блоках.network_interfacedisk clone customize data

Полный пример

provider "vsphere" {
    user = "admin"
    password = "MyAwesomePassword"
    vsphere_server = "pcc-XXX-XXX-XXX-XXX.ovh.com"
}

data "vsphere_datacenter" "dc" {
  name = "pcc-XXX-XXX-XXX-XXX_datacenter3113"
}

data "vsphere_datastore" "datastore" {
  name          = "pcc-001234"
  datacenter_id = "${data.vsphere_datacenter.dc.id}"
}

data "vsphere_compute_cluster" "cluster" {
  name          = "Cluster1"
  datacenter_id = "${data.vsphere_datacenter.dc.id}"
}

data "vsphere_network" "network" {
  name          = "vxw-dvs-57-virtualwire-2-sid-5001-Dc3113_5001"
  datacenter_id = "${data.vsphere_datacenter.dc.id}"
}

data "vsphere_virtual_machine" "template" {
  name          = "UBUNTU"
  datacenter_id = "${data.vsphere_datacenter.dc.id}"
}

resource "vsphere_virtual_machine" "vm" {
  name             = "vm01"
  resource_pool_id = "${data.vsphere_compute_cluster.cluster.resource_pool_id}"
  datastore_id     = "${data.vsphere_datastore.datastore.id}"
  guest_id         = "${data.vsphere_virtual_machine.template.guest_id}"
  scsi_type        = "${data.vsphere_virtual_machine.template.scsi_type}"

  network_interface {
    network_id = "${data.vsphere_network.network.id}"
  }

  disk {
    label = "disk0"
    size  = "${data.vsphere_virtual_machine.template.disks.0.size}"
  }

  clone {
    template_uuid = "${data.vsphere_virtual_machine.template.id}"

    customize {
      linux_options {
        host_name = "vm01"
        domain     = "example.com"
      }

      network_interface {
        ipv4_address = "192.168.1.2"
        ipv4_netmask = 24
      }

      ipv4_gateway    = "192.168.1.254"
      dns_suffix_list = ["example.com"]
      dns_server_list = ["192.168.1.1"]
    }
  }
}

3… 2… 1… Зажигание

Давайте посмотрим, как использовать наш новый файл конфигурации с Terraform…

Инициализация

Теперь, когда наш файл конфигурации готов, мы сможем использовать его для создания нашей виртуальной машины. Начнем с инициализации рабочей среды с помощью terraform initкоманды. Это позаботится о загрузке поставщика vSphere и создании различных файлов, необходимых Terraform для работы.

$ terraform init

Initializing provider plugins...
- Checking for available provider plugins on https://releases.hashicorp.com...
- Downloading plugin for provider "vsphere" (1.10.0)...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

...

* provider.vsphere: version = "~> 1.10"

Terraform has been successfully initialized!
...

Строить планы

Следующим шагом является выполнение terraform planкоманды, чтобы убедиться, что наш файл конфигурации не содержит ошибок, и визуализировать все действия, которые будет выполнять Terraform.

$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

data.vsphere_datacenter.dc: Refreshing state...
data.vsphere_compute_cluster.cluster: Refreshing state...
data.vsphere_network.network: Refreshing state...
data.vsphere_datastore.datastore: Refreshing state...
data.vsphere_virtual_machine.template: Refreshing state...

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  + vsphere_virtual_machine.vm
      id:                                                   <computed>
      boot_retry_delay:                                     "10000"
      change_version:                                       <computed>
      clone.#:                                              "1"
      clone.0.customize.#:                                  "1"
      clone.0.customize.0.dns_server_list.#:                "1"
      clone.0.customize.0.dns_server_list.0:                "192.168.1.1"
      clone.0.customize.0.dns_suffix_list.#:                "1"
      clone.0.customize.0.dns_suffix_list.0:                "example.com"
      clone.0.customize.0.ipv4_gateway:                     "172.16.0.1"
      clone.0.customize.0.linux_options.#:                  "1"
      clone.0.customize.0.linux_options.0.domain:           "example.com"
      clone.0.customize.0.linux_options.0.host_name:        "vm01"
      clone.0.customize.0.linux_options.0.hw_clock_utc:     "true"
      clone.0.customize.0.network_interface.#:              "1"
      clone.0.customize.0.network_interface.0.ipv4_address: "192.168.1.2"
      clone.0.customize.0.network_interface.0.ipv4_netmask: "16"
      clone.0.customize.0.timeout:                          "10"
      clone.0.template_uuid:                                "42061bc5-fdec-03f3-67fd-b709ec06c7f2"
      clone.0.timeout:                                      "30"
      cpu_limit:                                            "-1"
      cpu_share_count:                                      <computed>
      cpu_share_level:                                      "normal"
      datastore_id:                                         "datastore-93"
      default_ip_address:                                   <computed>
      disk.#:                                               "1"
      disk.0.attach:                                        "false"
      disk.0.datastore_id:                                  "<computed>"
      disk.0.device_address:                                <computed>
      ...

Plan: 1 to add, 0 to change, 0 to destroy.

Перед продолжением важно уделить время проверке всей информации, возвращаемой командой. Было бы беспорядком удалять виртуальные машины в производственной среде из-за ошибки в файле конфигурации… В приведенном ниже примере мы видим, что Terraform создаст новый ресурс (здесь виртуальная машина), а не изменит и не удалит ничего, что в точности Цель!

Применять

На последнем этапе terraform applyкоманда фактически настроит инфраструктуру в соответствии с информацией, содержащейся в файле конфигурации. В качестве первого шага planкоманда будет выполнена, и Terraform попросит вас подтвердить ее, набрав yes.

$ terraform apply
...

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

vsphere_virtual_machine.vm: Creating...
  boot_retry_delay:                                     "" => "10000"
  change_version:                                       "" => "<computed>"
  clone.#:                                              "" => "1"
  clone.0.customize.#:                                  "" => "1"
  clone.0.customize.0.dns_server_list.#:                "" => "1"
  clone.0.customize.0.dns_server_list.0:                "" => "192.168.1.1"
  clone.0.customize.0.dns_suffix_list.#:                "" => "1"
  clone.0.customize.0.dns_suffix_list.0:                "" => "example.com"
  clone.0.customize.0.ipv4_gateway:                     "" => "192.168.1.254"
  clone.0.customize.0.linux_options.#:                  "" => "1"
  clone.0.customize.0.linux_options.0.domain:           "" => "example.com"
  clone.0.customize.0.linux_options.0.host_name:        "" => "terraform-test"
  clone.0.customize.0.linux_options.0.hw_clock_utc:     "" => "true"
  clone.0.customize.0.network_interface.#:              "" => "1"
  clone.0.customize.0.network_interface.0.ipv4_address: "" => "192.168.1.2"
  clone.0.customize.0.network_interface.0.ipv4_netmask: "" => "16"
  clone.0.customize.0.timeout:                          "" => "10"
  clone.0.template_uuid:                                "" => "42061bc5-fdec-03f3-67fd-b709ec06c7f2"
  clone.0.timeout:                                      "" => "30"
  cpu_limit:                                            "" => "-1"
  cpu_share_count:                                      "" => "<computed>"
  cpu_share_level:                                      "" => "normal"
  datastore_id:                                         "" => "datastore-93"
  default_ip_address:                                   "" => "<computed>"
  disk.#:                                               "" => "1"
...
vsphere_virtual_machine.vm: Still creating... (10s elapsed)
vsphere_virtual_machine.vm: Still creating... (20s elapsed)
vsphere_virtual_machine.vm: Still creating... (30s elapsed)
...
vsphere_virtual_machine.vm: Still creating... (1m50s elapsed)
vsphere_virtual_machine.vm: Creation complete after 1m55s (ID: 42068313-d169-03ff-9c55-a23e66a44b48)

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Когда вы подключаетесь к vCenter вашего частного облака, вы должны увидеть новую виртуальную машину в инвентаре!

Следующие шаги

Теперь, когда мы увидели стандартный рабочий процесс Terraform, вы можете протестировать некоторые изменения в вашем файле конфигурации. Например, вы можете добавить еще один виртуальный диск к своей виртуальной машине, изменив блок ресурса virtual_machine следующим образом:

disk {
  label = "disk0"
  size  = "${data.vsphere_virtual_machine.template.disks.0.size}"
}

disk {
  label = "disk1"
  size  = "${data.vsphere_virtual_machine.template.disks.0.size}"
  unit_number = 1
}

Затем запустите, terraform planчтобы увидеть, что Terraform собирается сделать, чтобы согласовать состояние инфраструктуры с вашим файлом конфигурации.

$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

data.vsphere_datacenter.dc: Refreshing state...
data.vsphere_datastore.datastore: Refreshing state...
data.vsphere_network.network: Refreshing state...
data.vsphere_compute_cluster.cluster: Refreshing state...
data.vsphere_virtual_machine.template: Refreshing state...
vsphere_virtual_machine.vm: Refreshing state... (ID: 4206be6f-f462-c424-d386-7bd0a0d2cfae)

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  ~ vsphere_virtual_machine.vm
      disk.#:                  "1" => "2"
      disk.1.attach:           "" => "false"
      disk.1.datastore_id:     "" => "<computed>"
      ...


Plan: 0 to add, 1 to change, 0 to destroy.

Если вы согласны с предложением действия terraform, вы можете запустить его повторно terraform apply, чтобы добавить новый виртуальный диск к вашей виртуальной машине.

Приберись

Когда вы закончили свои тесты, и вы больше не требуется полезность инфраструктуры, у НУ можете просто запустить terraform destroyкоманду, чтобы удалить все ранее созданные ресурсы. Будьте осторожны с этой командой, так как после этого нет возможности вернуть ваши данные!

$ terraform destroy

data.vsphere_datacenter.dc: Refreshing state...
data.vsphere_compute_cluster.cluster: Refreshing state...
data.vsphere_datastore.datastore: Refreshing state...
data.vsphere_network.network: Refreshing state...
data.vsphere_virtual_machine.template: Refreshing state...
vsphere_virtual_machine.vm: Refreshing state... (ID: 42068313-d169-03ff-9c55-a23e66a44b48)

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  - destroy

Terraform will perform the following actions:

  - vsphere_virtual_machine.vm


Plan: 0 to add, 0 to change, 1 to destroy.

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes

vsphere_virtual_machine.vm: Destroying... (ID: 42068313-d169-03ff-9c55-a23e66a44b48)
vsphere_virtual_machine.vm: Destruction complete after 3s

Destroy complete! Resources: 1 destroyed.

В этой статье мы увидели, как развернуть виртуальную машину с файлом конфигурации Terraform. Это позволило нам узнать основные команды plan, applyи destroy, а также понятия provider, dataи resource. В следующей статье мы разработаем этот пример, изменив его, чтобы сделать его более адаптируемым и универсальным.

Федерация  — это бета-функция, предлагаемая всем клиентам OVH Private Cloud с vCenter 6.5 . Если вы хотите принять участие в бета-тестировании, обратитесь в нашу службу поддержки. Это позволяет использовать внешний Microsoft Active Directory в качестве источника аутентификации для доступа к серверу VMware vCenter . Реализация этой функции стало возможным благодаря OvH в команде DevOps , которые разработали инновационный и уникальный API , который добавляет дополнительные возможности для тех , предлагаемых VMware. Действительно, в настоящий момент невозможно настроить источники идентификаторов через собственный API vCenter.



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

Зачем?

По умолчанию права доступа к vCenter в частном облаке управляются непосредственно этим vCenter. Пользователи создаются локально (localos или домен SSO), и все механизмы управления доступом ( RBAC ) управляются службой SSO . Включение федерации делегирует управление пользователями Microsoft Active Directory (AD). В результате сервер vCenter будет взаимодействовать с контроллером домена, чтобы гарантировать, что пользователь, пытающийся подключиться, является тем, кем он себя называет. VCenter сохраняет управление ролями и привилегиями для объектов, которыми он управляет. После настройки федерации можно связать пользователей AD с ролями vCenter, чтобы они могли получать доступ и / или управлять определенными объектами в инфраструктуре (виртуальными машинами, сетями, папками и т. Д.).


Одним из основных применений этого будет облегчение доступа к vCenter для администраторов за счет уменьшения количества учетных записей, необходимых для обслуживания различных элементов инфраструктуры. Кроме того, появится возможность расширить и унифицировать политику управления паролями между Active Directory и vCenter Private Cloud.

Тот факт, что федерацией можно управлять через API OVH, позволяет автоматизировать настройку, а также поддерживать ее в рабочем состоянии. Наконец, очень просто добавить проверки в любой инструмент мониторинга (Nagios, Zabbix, Sensu и т. Д.) Для мониторинга состояния Федерации и прав, назначенных пользователям.

Вот пример простого сценария PowerShell, который будет периодически проверять, находится ли конфигурация федерации в желаемом состоянии:

Архитектура и предпосылки

Поскольку vCenter должен будет взаимодействовать с контроллерами домена, первым шагом будет разрешение потоков между этими элементами. Есть несколько способов достичь этой цели, например, объединить OVHCloud Connectс частным шлюзом . Для изучения всех различных возможностей потребуется целая статья, поэтому мы советуем вам связаться с OVH или одним из наших партнеров, чтобы помочь вам в выборе наиболее подходящей архитектуры. Следующая диаграмма дает вам упрощенный обзор того, как это может выглядеть:



После подключения вам необходимо убедиться, что вы собрали следующую информацию, прежде чем начинать процесс настройки:

• Ваши учетные данные OVH (ник и пароль)
• Имя вашего частного облака (в форме 

  pcc-X-X-X-X

  )
• Необходимая информация об инфраструктуре Active Directory, а именно:
  
  • Краткое и длинное имя домена Active Directory (например,

    contoso

    и 

    contoso.com

    )
  • IP-адрес контроллера домена
  • Имя пользователя и пароль учетной записи AD с достаточными правами для просмотра каталога
  • Расположение групп и пользователей в иерархии AD как «базовое DN» (пример:) 

    OU = Users, DC = contoso, DC = com

    . Следует отметить, что хотя информация о группе является обязательной, в настоящее время ее невозможно использовать для управления аутентификацией.
  • Список пользователей Active Directory, которых вы хотите привязать к vCenter. Необходимо будет указать имена пользователей в виде username@FQDN.domain (например,

    federation@contoso.com

    )

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

Активация и настройка

После того, как вы соберете всю необходимую информацию, можно будет активировать и настроить Федерацию. Операция будет проходить в три этапа:

1. Активация связи между Active Directory и частным облаком
2. Привязка одного или нескольких пользователей AD к частному облаку
3. Назначение прав пользователям

На данный момент конфигурация доступна только через OVH API, но в среднесрочной перспективе это будет возможно сделать через панель управления OVH.  API предлагает все необходимые параметры для активации, настройки или даже удаления федерации частного облака:

Включение соединения между AD и частным облаком

Перейдите на сайт проводника API и выполните аутентификацию, используя свои учетные данные OVH. Если у вас его еще нет, получите имя (также называемое serviceName в API) своего частного облака, так как оно будет обязательным для всех остальных шагов настройки. Вы можете получить доступ к этой информации, выполнив GET для URI / SpecialCloud:



Включите федерацию, предоставив всю информацию об Active Directory с помощью POST в URI- адресе / SpecialCloud / {serviceName} / federation / activeDirectory . Вся запрашиваемая информация обязательна:



Активация Федерации займет некоторое время и будет происходить в фоновом режиме. Вы можете следить за ходом операции через панель управления OVH:



После завершения вы можете получить идентификатор федерации, отправив запрос GET на URI- адрес / SpecialCloud / {serviceName} / federation / activeDirectory :

Привязка одного или нескольких пользователей AD

Теперь, когда ваш AD объявлен в vCenter Private Cloud, мы сможем привязать к нему пользователей Active Directory. Обратите внимание, что даже если ваши пользователи связаны, с ними не будет связанных ролей vCenter, поэтому они не смогут войти в систему.

Чтобы привязать пользователя, вам нужно будет отправить запрос POST на /dedicatedCloud/{serviceName}/federation/activeDirectory/{activeDirectory}/grantActiveDirectoryUser URI, указав полное имя пользователя:



Убедитесь, что пользователь присутствует в поисковом подразделении, которое вы указали при связывании AD с vCenter. Еще раз, вы можете проверить, что задача импорта выполнена через API или через панель управления:



Вы также должны получить электронное письмо о том, что пользователь был импортирован.

Назначение прав доступа

Последним шагом будет предоставление пользователям прав доступа к различным объектам виртуальной инфраструктуры. Этот шаг не отличается от обычного способа управления правами пользователей частного облака. Это можно сделать через API или панель управления OVH.



Теперь вы должны иметь возможность войти в свой vCenter с пользователями вашего AD и начать управлять своим частным облаком!

В этом посте мы увидели, как активировать опцию «Федерация» и какие преимущества она дает пользователям частного облака OVH. В следующей публикации мы поговорим о еще одной новой функции: Granular Rights. Так что следите за новостями в блоге OVH!

Управление выпусками корпоративного программного обеспечения — непростая задача: обновление инфраструктуры, борьба с опасениями, что редактор программного обеспечения их не поддержит, обновление лицензий для совместимости с новыми версиями и принятие всех мер предосторожности для отката, если что-то не работает должным образом. ожидается…

С OVH Private Cloud мы избавляем вас от этой сложности. Мы управляем этим трудоемким и стрессовым аспектом, чтобы вы могли сосредоточиться на своем бизнесе и производстве.

Но это не значит, что это не проблема для нас.

Обновление сотен vSphere 5.5 до 6.0

vSphere — это ведущий продукт предложения Private Cloud, он является частью пакета SDDC, предоставляемого VMware. vSphere — это программное обеспечение, позволяющее пользователю управлять своими хостами, хранилищем, сетью… Через клиента он может создавать кластеры с этими активами для надежного, стабильного и высокодоступного размещения производственной среды.

С сентября 2018 года поддержка vSphere (vCenter, ESXi…) версии 5.5 со стороны VMware прекращается. Обладая безопасностью и стабильностью инфраструктуры частного облака, мы начали процессы обновления для всех vCenter.



У нас было около 850 vCenter в версии 5.5 в производстве, что представляет собой значительную работу по обновлению всего, если она выполняется вручную. Но в OVH у нас есть общий лейтмотив: автоматизировать все человеческие действия  для повышения эффективности и избегать ошибок.

Так нам удалось обновить 850 vCenter с версии 5.5 до версии 6.0 за 4 недели. Другими словами, более 210 vCenter в неделю, 30 vCenter в день , с командой из 10 человек, выполняющих это обслуживание в фоновом режиме, без какого-либо влияния на производительность клиентов.

Наша команда разработчиков разработала и создала набор скриптов (которые мы внутри себя называем «роботом») для автоматизации обновлений vCenter несколько лет назад. Этот робот сильно изменился с момента появления продукта Private Cloud и следует за нами с версии 4.1 до 6.5, работа над которой еще продолжается.

Мы столкнулись с множеством проблем при настройке автоматических действий, таких как повреждение базы данных, службы, не интегрированные в систему единого входа (было очень сложно управлять им в версиях 5.0 и 5.1), а также отпечаток, который не обновлялся для всех служб., очень сложно устранить неисправность и воспроизвести ее. У нас даже были некоторые операционные системы, которые блокировали обновления программного обеспечения, из-за чего все было жестко остановлено.

Наши операционные группы много работали с группой поддержки VMware, чтобы найти обходные пути для возникающих проблем и автоматизировать их с помощью команды разработчиков. Это привело к созданию базы знаний VMware для уведомления клиентов о проблемах, с которыми мы столкнулись и которые были признаны VMware ошибками. Команды провели много ночей, чтобы обеспечить минимальное влияние доступности vSphere для клиентов.

Обновление апгрейдера: новая версия робота

Все эти проблемы убеждают нас действовать по двум причинам. Во-первых, запустите новую версию робота обновления , создавая меньше ошибок, имея более быстрое выполнение с точки зрения клиента, более надежное и надежное. Во-вторых, мы отказались от процесса обновления по умолчанию с использованием обновления программного обеспечения VMware для решения, в котором мы начинаем со только что установленного обновленного стека vCenter на обновленной виртуальной машине, а затем повторно подключаем все компоненты (базу данных, NSX…) к этому новому vCenter. .

Это значительно повысило стабильность наших услуг, поскольку мы обеспечиваем новую работоспособную и обновленную основу для vCenter. Все это резко сократило количество вмешательств наших SRE в инфраструктуры частного облака.

Если суммировать наши действия: мы проверяем, что служба работает, прежде чем что-либо делать, затем мы готовим все наши сохранения и снимки для подготовки к обновлению. Как только это будет сделано, мы развернем нашу автоматизацию, чтобы запустить обновление. Каждый шаг включает автоматическую проверку, чтобы убедиться, что все действия выполнены.

Мы создали этого робота для обновления в роботе-оркестраторе, который, в соответствии с введенными параметрами, будет создавать задачи обновления для каждого частного облака, связанного с обслуживанием, и будет планировать его в автоматические даты в течение как минимум 72 часов с учетом рассмотрения клиента. но также количество запускаемых обновлений по часам и критическим периодам (например, Черная пятница или Зимние распродажи). Клиенты могут изменить расписание своих обновлений с помощью диспетчера в части «Операции», чтобы выполнить обслуживание в более удобное для их производства время.



Наши команды SRE следят за роботами и следят за тем, чтобы техобслуживание выполнялось должным образом и в запланированное время.






Подводя итоги, мы перешли от необходимости автоматизировать операцию обновления vCenter, которая должна занимать не менее 12 часов на каждый vCenter, к первой версии автоматизации, которая позволяет выполнить эту операцию за 4 часа, но с слишком высокий уровень ошибок (20%) из-за повторяющихся ошибок, которые SRE приходилось исправлять вручную. Теперь вторая версия является прочной, надежной и стабильной , позволяющей избежать известных проблем и создавать только редкие и уникальные проблемы, которые будут исправлены в процессе автоматизации на тщательно подобранном этапе.

Что дальше?

В ближайшие месяцы последуют другие мероприятия по техническому обслуживанию, обновление хоста с версии 5.5 до версии 6.0, обновление нашей опции Veeam Backup с 8.0 до версии 9.5, обновление нашей опции Zerto с 5.0 до 5.5 и множество других обновлений наших внутренних машин. для обеспечения регулярного аудита PCI-DSS.

Мы сохраним ту же прозрачность и коммуникацию , пока мы прислушиваемся к вашим отзывам и улучшаем нашу систему обслуживания.