Глава 5. Развёртывание виртуального кластера песочницы

Перед установкой своих виртуальных экземпляров и их предоставления под Ceph, нам необходимо рассмотреть несколько моментов. Всё то программное обеспечение, которое мы будем применять, является программным обеспечением с открытым исходным кодом, а те версии, которые были использованы в нашем тестировании определены далее. Авторы этой книги разработали и проверили данный процесс в macOS X 10.12. Он также должен работать в macOS X 10.9 или более поздних версиях или в системах Linux.

Для Microsoft Windows машины хоста должны применять абсолютный путь для исполнения команд VBoxManage, которым обычно является C:\Program Files\Oracle\VirtualBox\VBoxManage.exe.

Общие системные требования для VirtualBox зависят от общего числа и настройки виртуальных машин, применяемых поверх этой системы. Ваш хост VirtualBox должен предлагать некий процессор с типом x86 (Intel или AMD), несколько гигабайт оперативной памяти (для исполнения от четырёх до семи виртуальных машин Ceph), несколько гигабайт дискового пространства, а также некое интернет- соединение. Перво- наперво мы выгружаем VirtualBox с http://www.virtualbox.org/, открываем его файл архива, а затем следуем указанной процедуре установки. Та версия VirtualBox, которую мы применяли при написании данной главы такова:

$ VBoxManage --version
5.1.18r114002
		

ЧТобы воспользоваться поставщиком VirtualBox, нам теперь необходимо установить Vagrant. Vagrant позволит нам создавать индивидуальные настройки для всех типов процессов Ceph и сделает возможной тонкую настройку всей установки. Данная настройка хранится в некотором отдельном файле, который упрощает всё управление нашими виртуальными экземплярами. Мы можем определять варианты в данном файле, в том числе сколько экземпляров каждого типа мы желаем исполнять, какой объём и каких именно системных ресурсов должно им выделяться, какая гостевая операционная система должна устанавливаться в них, и даже те параметры тонкой настройки самого ядра ОС, которые мы бы желали установить. Vagrant может быть выгружен по адресу https://www.vagrantup.com/ и доступен для macOS X, Linux и Windows. Самая последняя версия Vagrant, которую мы проверяли для подобной установки своей среды песочницы была следующей:

$ vagrant --version
Vagrant 1.9.3
		

Vagrant и VirtualBox будут применены для установки и запуска виртуальных машин. Когда мы получим их в рабочем виде, нам понадобится установить в них Ceph, а также настроить их надлежащим образом, чтобы обеспечить корректный запуск процессов Ceph, предполагая выделенные им обязанности и взаимодействие со всеми остальными процессами в данном кластере. Для первоначального запуска всего кластера Ceph мы воспользуемся в своих виртуальных машинах ceph-ansible (https://github.com/ceph/ceph-ansible). ceph-ansible является развиваемой сообществом системой управления, которая автоматизирует оснащение как кластера для тестирования, так и промышленные реализации. Мы будем применять очень схожий с разработанным для оснащения промышленных установок механизм при установке какого- то кластера Ceph в своей среде песочницы.

Одним из предварительных требований ceph-ansible является установка Ansible в нашей системе хоста. Ansible (https://www.ansible.com) является системой управления установкой с открытым исходным кодом, которая применяется для автоматизации предоставления программного обеспечения и автоматического развёртывания. Для оснащения ресурсами клиентских узлов с машины управления Ansible применяет ssh. Мы записываем плейбуки Ansible в распространённом формате YAML, который содержит инструкции для установки и настройки желаемых нами ресурсов. Заполняется некий файл учёта ресурсов (inventory), исходя из которого управляющая машина узнаёт о том наборе узлов, который подлежит управлению, а также все их характеристики. Для установки некоторого кластера в среде песочницы не требуется глубокий опыт работы с Ansible, хотя его распространённость растёт и вы можете обнаружить что стоит изучить его позже для своих собственных целей. {Прим. пер.: отсылаем вас для этого к нашему переводу вышедшей в мае 2017 второй редакции Полного руководства Ansible Джесс Китинг.} Для установки своей среды песочницы мы воспользовались такой версией Ansible:

$ ansible --version
ansible 2.2.2.0
		

Следуйте инструкциям выгрузки и установки, которые вы можете найти на https://www.ansible.com. Вам может вначале потребоваться установить pip. ВMac OS X вам также может понадобиться загрузить Xcode Apple из https://developer.apple.com/xcode/ чтобы установить gcc.

И, наконец, чтобу проверить что вы выгрузили и применяете надлежащую версию ceph-ansible, мы установим git, если он ещё не установлен у вас.

$ git --version
git version 2.9.3 (Apple Git-75)
		

Git является одной из самых распространённых систем управления версиями и она разработан для распределённых и нелинейных рабочих потоков. Он позволяет нам выбирать некую определённую версию репозитория удалённого кода и может осуществлять возврат во времени к заданному моменту необходимое состояние всех файлов в рамках такого репозитория. Git является программным обеспечением с открытым исходным кодом и доступен к выгрузке по адресу https://git-scm.com/. В нашем случае нет требований по определённой требуемой версии git, хотя и рекомендуется устанавливать наиболее последнюю.

Теперь, когда мы обсудили все необходимые первоначальные зависимости, мы продолжим установку ceph-ansible и настройку некоторой среды песочницы в вашей машине.

Самый первый шаг состоит в выгрузке в вашу машину наиболее последней копии ceph-ansible. Важно отметить, что все изменения, которые мы осуществим при начальной загрузке некоторого кластера Ceph будут выполнены внутри какого- то выделенного каталога, поэтому мы воспользуемся cd для того чтобы переместиться в соответствующее местоположение перед выгрузкой. Приводимая ниже команда выгрузит ceph-ansible вовнутрь нового каталога с названием ceph-ansible в вашем текущем каталоге:

$ git clone https://github.com/ceph/ceph-ansible.git ceph-ansible
		

Если вы желаете, чтобы название вашего каталога как- то отличалось от ceph-ansible, измените соответствующий текст в самом последнем поле в приведённой выше команде. После того как все последующие изменения и команды выполнятся внутри указанного каталога, нам понадобится выполнить cd в него:

$ cd ceph-ansible
		

Теперь мы находимся в необходимом каталоге ceph-ansible. Этот каталог содержит необходимый код для всех плейбуков Ansible, которые будут применены для настройки и установки Ceph. Сообщество Ceph активно осуществляет разработку в данном репозитории, поэтому самые последние состояния могут быть не стабильными или включать в свой состав несовместимые изменения и, тем самым, могут оказаться не идеальными для работы с ними. К счастью, git предоставляет нам возможность возврата к некоторой стабильной версии по времени, когда мы знаем, что данный механизм развёртывания работает в соответствии с ожиданиями. Мы воспользуемся такую возможность здесь для возврата:

$ git checkout v2.2.0
		

Такая v2.2.0 имеет название тега git Мы не желаем в подробностях обсуждать теги git, поскольку это выходит за рамки данной книги, однако в своей основе приведённая выше команда осуществит откат назад к версии 2.2.0 в данном репозитории. Применяя теги git мы можем перемещаться к любой контрольной точке, которая была отмечена соответствующим образом сопровождающими данный репозиторий.

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

Наш репозиторий ceph-ansible содержит различные типы файлов настройки. Они содержат файлы настройки, относящиеся к Ansible и относящиеся к Vagrant. Данный репозиторий также содержит те примеры, которые мы в конечном итоге представим с целью развёртывания кластера. Для целей данной главы мы изменим эти примеры файлов для установки своей среды локальной песочницы, однако они также могут быть модифицированы и для оснащения кластера в промышленной среде.

Мы персонализируем следующие файлы примеров ля оснастки песочницы:

Мы начнём с отправки специфичных для vagrant параметров настройки прежде чем мы приступим к индивидуальной настройке необходимых параметров для плейбука Ansible.

Скопируем vagrant_variables.yml.sample в vagrant_variables.yml, выполнив такую команду:

$ cp vagrant_variables.yml.sample vagrant_variables.yml
		

Откроем vagrant_variables.yml в своём любимом текстовом редакторе и изменим следующие переменные на указанные ниже значения:

mon_vms: 1 # A single monitor node is sufficient for now
osd_vms: 3
mds_vms: 0
rgw_vms: 0
nfs_vms: 0
rbd_mirror_vms: 0
client_vms: 1 # A client node to run CLI commands on the cluster
iscsi_gw_vms: 0
mgr_vms: 0
		

Эти изменения свидетельствуют о том, что мы создадим одну виртуальную машину, которая будет исполнять демон монитора Ceph, три, которые будут исполнять один или более процессов OSD и одну для исполнения клиентов. На протяжении данной главы мы будем возвращаться к данному файлу множество раз, поскольку именно здесь мы управляем общим числом ВМ, которые представляют наш работающий кластер Ceph. Когда мы завершим со своим первоначальным построением кластера Ceph, мы будем применять данный файл для масштабирования своего кластера вверх (или вниз) соответствующим образом.

Посредством vagrant_variables.yml мы можем также управлять тем дистрибутивом Linux, который будет устанавливаться на наши виртуальные машины Ceph. Значением по умолчанию является Ubuntu Xenial 16.04, на что указывает ceph/ubuntu-xenial.

Необходимого vagrant box, предоставляемого примером файла vagrant_variables.yml, должно быть достаточным для установки, в нашем случае, кластера Ceph, поэтому для данного упражнения мы последуем за установленными в нём значениями по умолчанию.

Следующий шаг состоит в создании некоторой копии основного плейбука Ansible с названием site.yml.sample в site.yml:

$ cp site.yml.sample site.yml
		

Для своего упражнения нам нет нужды изменять имеющееся содержимое данного файла. Все имеющиеся параметры передаются в предоставляемый кластер Ceph внутри меющейся среды песочницы.

Затме мы копируем необходимый файл переменных группы хоста в файл с подходящим названием:

$ cp group_vars/all.yml.sample group_vars/all.yml
		

Эти переменные группы хоста управляют той версией Ceph, которая будет установлена на соответствующих узлах. Нам понадобится изменить соответствующие опции настройки во вновь созданном файле чтобы указать Ansible где находить необходимые пакеты Ceph, которые нам понадобится выгружать. В настоящее время мы рекомендуем пакеты Ceph тем образом, как это рекомендует сама команда Ceph: извлекая их с их официального зеркала по адресу https://download.ceph.com/.

Откройте только что выгруженный файл с названием group_vars/all.yml в своём любимом текстовом редакторе и удалите комментарий в следующей строке:

#ceph_origin: 'upstream' # or 'distro' or 'local'
		

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

ceph_origin: 'upstream' # or 'distro' or 'local'
		

Она назначает значение upstream имеющейся переменной ceph_origin. Вся оставшаяся часть данной строки будет проигнорирована, благодаря # и тому, что все последующие символы воспринимаются в качестве комментария.

Данное значение upstream указывает поставщику Ceph выгружать двоичные файлы и пакеты Ceph из источника в реальном режиме вместо того чтобы отыскивать их локально. Если вам необходимо выгрузить пакеты Ceph отдельно или вы желаете применять те, которые предоставляются дистрибутивом Linux, и вы в курсе того как работает Ansible, вы можете изменить эту опцию на distro или local. Выполнения этого, однако, является дополнительной темой, которая выходит за пределы данной главы и вы будете действовать по своему собственному усмотрению. {Прим. пер.: ещё раз напоминаем Вам о нашем переводе вышедшей в мае 2017 второй редакции Полного руководства Ansible Джесс Китинг.}

Раз мы обновили данную строку ceph_origin, нам также необходимо уведомить своего поставщика где ему искать те пакеты, которые мы желаем применять. Мы осуществим это убрав комментарий в последующих строках в нашем файле group_vars/all.yml вниз от той строки, которая сообщает # COMMUNITY VERSION:

Вот как выглядит соответствующий раздел в данном файле без наших изменений:

# STABLE
########

# COMMUNITY VERSION
#ceph_stable: false # use ceph stable branch
#ceph_mirror: http://download.ceph.com
#ceph_stable_key: https://download.ceph.com/keys/release.asc
#ceph_stable_release: kraken # ceph stable release
#ceph_stable_repo: "{{ ceph_mirror }}/debian-{{ ceph_stable_release }}"
		

Уберите признак комментария в пяти строках под COMMUNITY VERSION путём удаления первичного символа #. Нам также необходимо изменить установку ceph_stable на true и ceph_stable_release на jewel, раз мы желаем раскрутить некий кластер применяя какую- то стабильную версию имеющегося выпуска LTS Jewel. На тот момент когда мы пишем данные строки, Luminous всё ещё в разработке, но на момент чтения он получит общую доступность. Вы можете поэкспериментировать впоследствии с последним, выбрав здесь Luminous, однако мы предлагаем начать с оснащения Jewel. Все данные строки в group_vars/all.yml должны выглядеть примерно так:

# STABLE
########

# COMMUNITY VERSION
ceph_stable: true # use ceph stable branch
ceph_mirror: http://download.ceph.com
ceph_stable_key: https://download.ceph.com/keys/release.asc
ceph_stable_release: jewel # ceph stable release
ceph_stable_repo: "{{ ceph_mirror }}/debian-{{
ceph_stable_release }}"
		

Сохраните этот файл и покиньте свой редактор. Далее мы продолжим создание виртуальных машин и вывод кластера Ceph в поднятое состояние.

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

Это выполняется в два этапа:

Наша первая фаза применяет Vagrant для создания необходимых виртуальных машин. Основываясь на тех изменениях, которые мы внесли в свой файл vagrant_variables.yml по окончанию данного этапа нам надлежит увидеть в общей сложности созданными пять виртуальных машин: 1 для монитора Ceph, 3 для OSD Ceph и 1 для своего клиента.

$ vagrant up --no-provision --provider=virtualbox
		

Это укажет Vagrant создать необходимые ресурсы ЦПУ, оперативной памяти и хранилища для каждой виртуальной машины и поднять эти машины, загрузив их. Мы передаём необходимый флаг командной строки --no-provision чтобы обеспечить что нам не потребуется снабжать каждую машину Ansible после того как она перейдёт в поднятое состояние. Данный процесс предоставления требует чтобы все необходимые узды в нашем кластере были активными перед исполнением и, следовательно, мы осуществляем это на некотором заключительном этапе раз мы имеем все необходимые ВМ поднятыми и доступными друг для друга.

Vagrant может занять какое- то время на создание и выделение ресурсов каждой виртуальной машине в зависимости от тех ресурсов, которые доступны в вашем хосте. Данный рабочий поток Vagrant создаёт виртуальные машины последовательно, поэтому нам придётся подождать пока каждая из них не завершит загрузку.

Если ваш процессор намного старше (настолько, что он старше чем Intel Celeron или AMD Opteron), вам может потребоваться выбрать некий 32- битный образ ОС чтобы успешно загрузить необходимые виртуальные машины.

Когда команда vagrant up завершит исполнение, мы должны иметь все требующиеся виртуальные машины поднятыми и исполняющимися. Это можно проверить, выполнив проверку состояния, как это показано ниже:

$ vagrant status
		

Мы должны увидеть 5 созданных виртуальных машин с последующими за ними именами. Их порядок не существенен:

mon0 running    (virtualbox)
osd0 running    (virtualbox)
osd1 running    (virtualbox)
osd2 running    (virtualbox)
client0 running (virtualbox)
		

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

$ vagrant provision
		

Это исполнит необходимые воспроизведения (plays) Ansible и создаст требующиеся демоны Ceph соответственным образом на каждой машине. Это также потребует некоторого времени. Когда этот процесс завершится, мы должны получить в свои руки некий оснащённый и работающий кластер Ceph.

Мы можем убедиться что данный кластер установлен и жизнеспособен зарегистрировавшись на своём хосте клиента и выполнив следующую команду проверки состояния Ceph:

$ vagrant ssh client0
vagrant@ceph-client0:~$ sudo ceph status
    cluster 27af531f-31db-4eb9-a3e1-9e7592d2fec7
     heath HEALTH_OK
     monmap e1: 1 mons at {ceph-mon0=192.168.42.10:6789/0}
            election epoch 4, quorum 0 ceph-mon0
     osdmap e33: 6 osds: 6 up, 6 in
            flags sortbitwise,require_jewel_osds
      pgmap v86: 64 pgs, 1 pools, 0 bytes data, 0 objects
            202 MB used, 65131 MB / 65333 MB avail
                  64 active+clean
		

В последующих главах мы изучим в подробностях то, что сообщает нам данная команда; на текущий момент отметим, что значением её жизнеспособности (health) является HEALTH_OK.

Давайте повторно посетим свой файл vagrant_variables.yml, который мы до этого уже изменяли, чтобы отрегулировать общее число узлов прежде чем приступить к начальной загрузке своего кластера. Мы подправим общее число участников в данном файле до того масштаба, который нам нужен. Откройте данный файл в своём любимом редакторе. Прежде чем приступить к изменению те переменные, которые отражают ваши существующие узлы должны выглядеть примерно так:

mon_vms: 1
osd_vms: 3
mds_vms: 0
rgw_vms: 0
rbd_mirror_vms: 0
client_vms: 1
iscsi_gw_vms: 0
mgr_vms: 0
 	   

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

Почему мы выбираем 3?

Нечётное число экземпляров узлов Мониторов необходимо чтобы разрывать связи при выборе ведущего

В промышленных применениях реального мира многие кластеры небольшого раз мера предоставляют 3 Монитора, а авторы этих строк успешно работали с кластерами, имеющими много петабайт с 5 узлами мониторов.

Отредактируйте общее число узлов мониторов на 3, что изменит переменные следующим образом:

mon_vms: 3
osd_vms: 3
mds_vms: 0
rgw_vms: 0
nfs_vms: 0
rbd_mirror_vms: 0
client_vms: 1
iscsi_gw_vms: 0
mgr_vms: 0
 	   

Теперь, когда мы изменили свой файл vagrant_variables.yml, нам следует снова исполнить команду vagrant чтобы поднять две дополнительные ВМ с новыми демонами Мониторов:

$ vagrant up --no-provision --provider=virtualbox
		

Когда данная команда завершится, мы должны иметь в общей сложности 7 исполняющихся ВМ. Мы можем убедиться в этом следующим образом:

$ vagrant status | grep running
client0                   running (virtualbox)
mon0                      running (virtualbox)
mon1                      running (virtualbox)
mon2                      running (virtualbox)
osd0                      running (virtualbox)
osd1                      running (virtualbox)
osd2                      running (virtualbox)
		

Те два новых узла Монитора, которые мы только что раскрутили, ещё пока не имеют предоставленного на них Ceph и наш кластер пока не осведомлён о них пока мы не настроим и не запустим на них демоны Монитора. Запуск демонов Монитора настолько же прост, как и само предоставление этих узлов. Мы применим ту же самую команду, которой мы воспользовались ранее для предоставления всего кластера чтобы предоставить эти два дополнительных узла:

$ vagrant provision
		

Как только оснастка завершится, мы должны увидеть два своих вновь созданных узла Монитора в имеющемся кластере. Мы можем убедиться в этом зарегистрировавшись на своём клиенте и проверив самое последнее состояние (status) своего кластера:

vagrant@ceph-client0:~$ sudo ceph status
    cluster 27af531f-31db-4eb9-a3e1-9e7592d2fec7
     health HEALTH_OK
     monmap e3: 3 mons at {ceph-mon0=192.168.42.10:6789/0,ceph-mon1=192.168.42.11:6789/0,ceph-mon2=192.168.42.12:6789/0}
           election epoch 10, quorum 0,1,2 ceph-mon0,cephmon1,ceph-mon2
     osdmap e33: 6 osds: 6 up, 6 in
            flags sortbitwise,require_jewel_osds
      pgmap v86: 64 pgs, 1 pools, 0 bytes data, 0 objects
            202 MB used, 65131 MB / 65333 MB avail
                  64 active+clean
		

В данной главе мы подняли некий работающий кластер Ceph из рабочей области и последовательно масштабировали его без отключения. Мы воспользовались широко применяемыми инструментами с открытым исходным кодом Vagrant и VirtualBox чтобы помочь смоделировать некий реальный кластер Ceph. В своей следующей главе мы изучим ряд операций, которые мы можем выполнять для персонализации, наполнения и управления кластерами Ceph.