Глава 2. Развёртывание Ceph

Хотя некий тестовый кластер может быть развёрнут на любом оборудовании или VM (virtual machine - ВМ, виртуальной машине), для целей данной книги будет применяться некая комбинация Vagrant и VirtualBox. Это позволит нам быстро предоставлять необходимые ВМ и гарантировать согласованное окружение.

VirtualBox является свободно распространяемым гипервизором 2 типа (hosted, работающий в одном кольце с основной операционной системой), который в настоящее время разрабатывается Oracle. В сравнении с гипервизорами верхнего эшелона у него могут быть недостаточными производительность и функциональность, однако его лёгкий на подъём подход и поддержка множества OC выдвигают его в первые кандидаты для тестирования.

Vagrant поможет позволить некую среду, которая может содержать множество быстро и разумно создаваемых машин. Он работает с концепцией ящиков (boxes), которые являются предварительно определёнными шаблонами для их применения с гипервизорами и их Vagrantfile, которые определяют среду для построения. Они поддерживают большое число гипрвизоров и делают возможным портировать между ними некий Vagrantfile.

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

Посетите веб сайт VirtalBox по адресу https://www.virtualbox.org и выгрузите те пакеты, которые соответствуют используемой вами ОС.

Для установки Vagrant выполните следующие шаги:

ceph-deploy является официальным инструментом для развёртывания кластеров Ceph. Он работает основываясь на принципе наличия некоторого узла администратора с доступом через SSH (без пароля) для всех машин в вашем кластере Ceph; он также содержит некую копию всего файла настройки Ceph. Всякий раз когда вы выполняете действие некоторого развёртывания, он применяет SSH для соединения с вашими узлами Ceph для осуществления всех необходимых шагов. Хотя данный инструментарий ceph-deploy и является полностью поддерживаемым методом, который оставит вас с прекрасно работающим кластером Ceph, предоставляемое в настоящее время управление со стороны Ceph не будет настолько простым, как того бы хотелось. Кластеры большого размера также вызовут массу накладных расходов в случае применения ceph-deploy. По этой причине рекомендуется ограничиться применением ceph-deploy для целей тестирования или в промышленных кластерах небольшого масштаба, несмотря на то, что как вы увидите, инструменты координации (orchestration) позволяют быстрое развёртывание Ceph и вероятно лучше приспособлены для сред проверки, в которых вам может требоваться непрерывное построение кластеров.

Применение какого- либо инструментария координации (orchestration) является неким решением для того чтобы сделать процесс установки и управления Ceph более простым. Имеются различные доступные инструменты, например, Puppet, Chef, Salt и Ansible, причём все они имеют доступными модули Ceph. Если вы уже применяли некий инструментарий координации в своей среде, тогда мы бы порекомендовали вам продолжать его использование. Для целей данной книги будет применяться Ansible, причём для этого имеется целый ряд причин:

Все инструменты следуют одному и тому же принципу того, что вы предоставляете им некий реестр хостов и множество задач, подлежащих исполнению над этими хостами. На эти задачи часто ссылаются как на переменные, что делает возможной персонализацию данной задачи во время её исполнения. Инструменты координации (orchestration) разработаны для исполнения по некому расписанию с тем, чтобы если по какой- либо причине данное состояние или настройка некоторого хоста изменится, она будет корректно возвращена обратно в предназначенное для неё состояние при следующем исполнении.

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

Итак, применение средств координации (orchestration) не только даёт вам возможность более быстрого и менее подверженного ошибкам развёртывания, но также бесплатно предоставляет документирование и управление изменениями. Если вы пока не получали данной подсказки, именно это является тем, на что на самом деле стоит обратить своё внимание.

Как уже было отмечено, именно Ansible будет инструментом координации (orchestration), выбранным для данной книги. Давайте взглянем на него слегка более подробно.

Ansible является неким инструментом координации свободным от агента, написанном на Python, который применяет SSH для выполнения задач настройки на удалённых узлах. Он был выпущен впервые в 2012 и получил широкое распространение, причём он славится простотой освоения и невысокой траекторией изучения. Red Hat приобрела коммерческую компанию Ansible, Inc. в 2015 и по этой причине имеет очень хорошо разработанную и тесную интеграцию для развёртывания Ceph.

Именуемые планами (playbooks) файлы применяются в Ansible для описания перечня команд, действий и настроек для обслуживания определённых хостов или групп хостов и сохраняются в файловом формате YAML. Вместо наличия больших неуправляемых планов (playbooks), могут создаваться роли Ansible, которые позволяют некоторому плану содержать какую- то отдельную задачу, которая может впоследствии осуществлять целый ряд задач, связанных с этой ролью.

Применение SSH для соединения с удалёнными узлами и исполнение планов (playbooks) означает, что этот инструмент имеет очень малый вес и не требует никакого агента или некоторого централизованного сервера.

Для целей тестирования Ansible также хорошо интегрирован с Vagrant, некий план Ansible может быть определён как часть самого Vagrant, предоставляющая настройки и будет автоматически создавать некий файл учёта (inventory) из создаваемой ВМ Vagrant и исполнять данный план (playbook) при загрузке данных серверов. Это позволяет некоторому содержащему ОС кластеру Ceph развёртываться всего одной командой.

Поднимите свою созданную ранее среду Vagrant опять и соединитесь через SSH со своим сервером Ansible. Для данного примера будут необходимы только ansible, mon1 и osd1:

vagrant up ansible mon1 osd1
 	   

Добавьте Ansible ppa следующим образом:

$ sudo apt-add-repository ppa:ansible/ansible
 	   

Предыдущая команда предоставит вам следующий вывод:

Обновите исходные файлы APT (Advanced Package Tool) и установите Ansible:

Предыдущая команда предоставит вам следующий вывод:

Файл учёта ресурсов (inventory) Ansible применяется Ansible для справочной информации по всем известным хостам и тому, к каким группам они относятся. Некая группа определяется помещением её названия в квадратные скобки, причём группы могут встраиваться внутри прочих групп путём применения дочерних определений.

Прежде чем мы добавим хосты в свой файл учёта ресурсов, мы вначале должны настроить все свои удалённые узлы для работы с SSH (без паролей); в противном случае всякий раз, когда Ansible попытается соединиться с некоторой удалённой машиной, нам придётся вводить некий пароль.

Создайте следующим образом некий ключ SSH:

$ ssh-keygen
 	   

Предыдущая команда предоставит вам следующий вывод:

Скопируйте этот ключ на все удалённые хосты:

$ ssh-copy-id mon1
 	   

Предыдущая команда предоставит вам следующий вывод:

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

Теперь попытаемся зарегистрироваться в этой машине при помощи ssh mon1:

Для возврата в свою ВМ Ansible наберите exit.

Теперь давайте создадим необходимый нам файл учёта ресурсов Ansible.

Измените файл с названием hosts в /etc/ansible:

$ sudo nano /etc/ansible/hosts
 	   

Создайте две группы с названиями osds и mons и наконец третью группу с именем ceph. Эта третья группа будет содержать в качестве своих потомков созданные группы osds и mons.

Введите некие списки хостов в правильные группы следующим образом:

[mons]
mon1
mon2
mon3

[osds]
osd1
osd2
osd3

[ceph:children]
mons
osds
 	   

Большинство планов (playbooks) и ролей будут применять переменные; такие переменные могут переназначаться различными способами. Простейший из них состоит в создании файлов в соответствующих папках host_vars и groups_vars, что позволяет вам перекрывать значения переменных либо на основании участия в хостах или группах соответственно. Для этого проделайте следующие шаги:

Переменные следуют некому порядку старшинства; вы можете также создать некий файл all, который будет применяться ко всем группам. Однако, некая переменная в точности с таким же названием, которая находится в более определённой группе соответствия перепишет её. Все модули Ansible Ceph используют это чтобы иметь некий набор определённых по умолчанию переменных и далее позволяют вам определять другие значения для определённых ролей.

Чтобы проверить что Ansible работает правильно и что мы можем успешно делать соединения и удалённо исполнять команды, давайте воспользуемся командой Ansible ping для проверки одного из наших хостов. Отметим, что она не похожа некий сетевой ping. ping Ansible подтверждает что он способен взаимодействовать через SSH и удалённо выполнять команды:

Предыдущая команда предоставит вам следующий вывод:

Замечательно, это работает, теперь давайте исполним удалённо некую простую команду чтобы продемонстрировать всю мощность Ansible. Следующая команда получит текущую версию работающего ядра в определённом удалённом узле:

$ ansible mon1 -a 'uname -r'
 	   

Это именно то что мы и ожидали:

Чтобы продемонстрировать как работают планы (playbooks), приводимый ниже пример покажет некий небольшой план, который также применяет те переменные, которые мы настроили ранее:

- hosts: mon1 osd1
  tasks:
  - name: Echo Variables
    debug: msg="I am a {{ a_variable }}"
 	   

Теперь выполним этот план. Обратите внимание что команда выполнения плана отличается в этом специальном случае от обычно применяемых команд Ansible.

$ ansible-playbook /etc/ansible/playbook.yml
 	   

Предыдущая команда предоставит вам следующий вывод:

Данный вывод показывает исполнение нашего плана и на mon1, и на osd1, поскольку они состоят в группах, которые являются дочерними для нашей родительской группы ceph. Также отметим как этот вывод различается между данными двумя серверами, поскольку они выхватываются теми переменными, которые вы установили ранее в своём каталоге group_vars.

Наконец, самая последняя пара строк отображает общее состояние исполнения работы данного плана. Теперь вы можете вновь уничтожить свою среду Vagrant, чтобы подготовить её к работе в следующем разделе.

vagrant destroy --force
 	   

Это завершает наше введение в Ansible, однако это далеко не полное руководство. Рекомендуем вам изучить прочие ресурсы, чтобы получить более глубокое знание Ansible прежде чем применять его в промышленной среде. {Прим. пер.: мы частично перевели увидевшую свет в марте 2017 второй редакции Mastering Ansible, а теперь рассматриваем возможности перевода увидевшей свет в марте 2019 третьей редакции Mastering Ansible!}

Мы можем воспользоваться git для клонирования своего репозитория Ansible Ceph:

git clone https://github.com/ceph/ceph-ansible.git
sudo cp -a ceph-ansible/* /etc/ansible/
 	   

Предыдущая команда предоставит вам следующий вывод:

Давайте изучим некоторые из основных папок в своём репозитории git:

Чтобы иметь возможность развернуть некий кластер Ceph при помощи Ansible необходимо установить целый ряд ключевых переменных в вашем каталоге group_vars. Приводимые далее переменные требуются либо для установки, либо предлагаются к изменению установленных для них по умолчанию значений. Для всех остальных переменных предполагается, что вы прочтёте комментарии во всех файлах переменных.

Приводимые ниже переменные являются ключевыми в global:

#mon_group_name: mons
#osd_group_name: osds
#rgw_group_name: rgws
#mds_group_name: mdss
#nfs_group_name: nfss
...
#iscsi_group_name: iscsigws
 	   

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

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

Установите upstream для применения тех пакетов, которые создаются вашей командой Ceph, или distro для пакетов, создаваемых вашей группой поддержки дистрибутивов. Установка upstream рекомендуется если вы собираетесь иметь возможность обновлять Ceph независимо от своего дистрибутива.

По умолчанию для вашего кластера будет сгенерирован fsid и сохранён в некотором файле, на который можно будет ссылаться снова:

#fsid: "{{ cluster_uuid.stdout }}"
#generate_fsid: true
 	   

Вам не следует прикасаться к этому, если только вы не желаете управлять своим fsid или захотите жёстко закодировать этот fsid в своём файле групповой переменной:

#monitor_interface: interface
#monitor_address: 0.0.0.0
 	   

Один из них следует определить. Если вы используете некую переменную в group_vars, тогда вы вероятно пожелаете воспользоваться monitor_interface, которая является именем того интерфейса, как он виден самой ОС, так как он вероятно будет одним и тем же во всех группах mons. В противном случае, если вы определите monitor_address в host_vars, вы можете определить конкретный IP данного интерфейса, который очевидно будет различным во всех ваших трёх или большем числе групп mons.

#ceph_conf_overrides: {}
 	   

Не все переменные Ceph напрямую управляются Ansible, однако все предыдущие переменные представлены с той целью, чтобы позволить вам передавать любые дополнительные переменные в ваш файл ceph.conf и его соответствующие разделы. Вот некий пример как это могло бы выглядеть (обратите внимание на отступы):

ceph_conf_overrides:
  global
    variable1: value
  mon:
    variable2: value
  osd:
    variable3: value
 	   

Ключевые переменные в файле переменных OSD:

copy_admin_key: false
 	   

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

#devices: [] 
#osd_auto_discovery: false 
#journal_collocation: false 
#raw_multi_journal: false 
#raw_journal_devices: []
 	   

Это вероятно критически самый важный набор переменных во всей настройке Ansible. Они управляют тем какие диски применяются как OSD, а какие помещаются под журналы. Вы даже можете вручную определить те устройства, которые вы бы хотели применять в качестве OSD или вы можете использовать автоматическое выявление. Примеры в данной книге будут применять статические настройки устройств.

Переменная journal_collocationустанавливает желаете ли вы хранить сам журнал на том же самом диске, что и сами данные OSD; для него будет создан отдельный раздел.

Переменная raw_journal_devices позволяет вам определить те устройства, которые вы хотите применять для журналов. Достаточно часто некий отдельный SSD будет журналом для различных OSD, в этом случае включите raw_multi_journal и просто определите данное устройство журнала множество раз, никакие номера разделов не нужны если вы желаете чтобы Ansible проинструктировал ceph-disk создать их для вас.

Имеются главные переменные которые вам необходимо рассмотреть. Рекомендуется чтобы вы прочли все комментарии в своих файлах переменных чтобы просмотреть имеются ли ещё какие- то другие, которые вам может понадобиться изменить для своей среды.

Во Всемирном Интернете имеется ряд примеров, которые содержат полностью настроенные Vagranfile и связанные с ними планы (playbooks) Ansible, которые позволят вам поднять полностью функциональную среду Ceph всего лишь одной командой. Насколько это удобно, настолько это и не может помочь вам изучить как правильно настроить и применить модули Ceph Ansible, в сравнении с тем, как если бы вы разворачивали некий кластер Ceph на реальном оборудовании в некоторой промышленной среде. Таким образом, данная книга послужит вам руководством по настройке Ansible с нуля, хоть и работает на серверах, предоставляемых Vagrant.

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

Теперь присядьте поудобнее и наблюдайте как Ansible разворачивает ваш кластер:

Когда всё завершится, в предположении что Ansible исполнится без ошибок, соединитесь через SSH с mon1 и выполните приведённый ниже код. Если Ansible всё же столкнётся с проблемой, отмотайте вывод вверх и просмотрите ту часть, которая вызвала ошибку, текст данной ошибки должен предоставить вам ключ к тому почему произошёл отказ.

vagrant@mon1:~$ sudo ceph -s:
 	   

И это завершает всё развёртывание полностью работающего кластера Ceph при помощи Ansible.

Если вы желаете иметь возможность остановить данный кластер Ceph Vagrant без утраты той работы, которую вы выполнили на данный момент, вы можете исполнить следующую команду:

vagrant suspend
 	   

Это переведёт в состояние паузы все ваши ВМ в их текущем состоянии.

Следующая команда включит все ваши ВМ и восстановит их исполнение с того состояния, в котором вы их оставили:

vagrant resume
 	   

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

Рекомендуемым подходом было бы сохранение ваших настроек Ansible Ceph в репозитории git, что позволило бы вам отслеживать изменения и предоставило бы возможность реализации некоторого вида управления изменениями либо посредством наблюдения за фиксациями git, или заставляя персонал выставлять запросы слияния в свою основную ветвь.

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