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

{Прим. пер.: рекомендуем сразу обращаться к нашему переводу 2 издания вышедшего в феврале 2019 Полного руководства Ceph Ника Фиска}

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

В данной главе вы изучите следующие вопросы:

  • Подготовка некоторой тестовой среды при помощи Vagrant и VirtualBox

  • Изучение различий между ceph-deploy и инструментами координации

  • Преимущества применения средств координации

  • Установку и использование Ansible

  • Настройку имеющихся модулей Ansible Ceph

  • Развёртывание некоторого тестового кластера с помощью Vagrant и Ansible

  • Идеи по поводу того как управлять вашей настройкой Ceph

Подготовка вашего окружения при помощи Vagrant и VirtualBox

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

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

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

Требования системы

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

  • Некую ОС (операционную систему), совместимую с Vagrant и VirtualBox; они включают в свой состав Linux, macOS и Windows.

  • ЦПУ с 2 ядрами

  • 8 ГБ оперативной памяти

  • Включённые инструкции виртуализации во встроенном программном обеспечении материнской платы (или в её bios)

Получение и установка Virtualbox

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

 

Рисунок 1



Установка Vagrant

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

  1. Следуйте инструкциям установки с веб сайта Vagrant https://www.vagrantup.com/downloads.html для получения установки Vagrant в выбранной вами ОС:

     

    Рисунок 2



  2. Создайте некий новый каталог для своего проекта Vagrant, например ceph.

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

     

    Рисунок 3



    
    vagrant plugin install vagrant-hostmanager
     	   

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

     

    Рисунок 4



    
    vagrant box add bento/ubuntu-16.04
     	   

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

     

    Рисунок 5



    Теперь создайте некий пустой файл с названием Vagrantfile и поместите в него следующее:

    
    nodes = [
      { :hostname => 'ansible', :ip => '192.168.0.40', :box => 'xenial64'},
      { :hostname => 'mon1', :ip => '192.168.0.41', :box => 'xenial64' },
      { :hostname => 'mon2', :ip => '192.168.0.42', :box => 'xenial64' },
      { :hostname => 'mon3', :ip => '192.168.0.43', :box => 'xenial64' },
      { :hostname => 'osd1', :ip => '192.168.0.51', :box => 'xenial64', :ram => 1024, :osd => 'yes' },
      { :hostname => 'osd2', :ip => '192.168.0.52', :box => 'xenial64', :ram => 1024, :osd => 'yes' },
      { :hostname => 'osd3', :ip => '192.168.0.53', :box => 'xenial64', :ram => 1024, :osd => 'yes' }
    ]
     
    Vagrant.configure("2") do |config|
      nodes.each do |node|
        config.vm.define node[:hostname] do |nodeconfig|
          nodeconfig.vm.box = "bento/ubuntu-16.04"
          nodeconfig.vm.hostname = node[:hostname]
          nodeconfig.vm.network :private_network, ip: node[:ip]
    
          memory = node[:ram] ? node[:ram] : 512;
          nodeconfig.vm.provider :virtualbox do |vb|
            vb.customize [
              "modifyvm", :id,
              "--memory", memory.to_s,
            ]
            if node[:osd] == "yes"
              vb.customize [ "createhd", "--filename", "disk_osd-#
              {node[:hostname]}", "--size", "10000" ]
              vb.customize [ "storageattach", :id, "--storagectl", "SATA Controller", "--port", 3, "--device", 0, "--type", 
    	                     "hdd", "--medium", "disk_osd-#{node[:hostname]}.vdi" ]
            end
          end
        end
        config.hostmanager.enabled = true
        config.hostmanager.manage_guest = true
      end
    end
     	   
    [Совет]Совет

    На всякий случай, если вы встретите на данном этапе с ошибкой, вам необходимо запретить Hyper-V.

    Выполните vagrant up чтобы поднять все определённые в Vagrantfile ВМ:

     

    Рисунок 6



  4. Теперь давайте соединимся со своей ВМ ansible с применением ssh:

    
    vagrant ssh ansible
     	   

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

     

    Рисунок 7



    [Замечание]Замечание

    Если вы исполняете Vagrant под Windows, тогда команда ssh проинформирует вас что вам нужно воспользоваться неким клиентом SSH по вашему выбору и предоставит некоторые подробности по его использованию.

    PuTTY мог бы быть неплохим подспорьем в качестве некоего клиента SSH. В Linux данная команда соединит вас напрямую с необходимой ВМ. {Прим. пер.: с января 2018 Windows 10 и Server 2016 располагают встроенным OpenSSH, который не включён по умолчанию. Для включения клиента/ сервера OpenSSH вам следует пройти в Пуск > Приложения и возможности > Управление дополнительными возможностями > Клиент OpenSSH/ Сервер OpenSSH}.

    И имя пользователя, и пароль оба имеют значение vagrant. После регистрации вы обнаружите себя находящимся в оболочке Bash вашей ВМ ansible:

     

    Рисунок 8



    Просто наберите exit чтобы вернуться в машину своего хоста.

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

    
    vagrant destroy --force
     	   

Инструмент ceph-deploy

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, причём для этого имеется целый ряд причин:

  • Это предпочитаемый метод развёртывания в Red Hat, которая является владельцем обоих проектов, и Ceph, и Ansible

  • Он имеет хорошо проработанный и зрелый набор ролей и планов (playbooks) Ceph

  • Ansible имеет склонность быть более простым в изучении в случае, если вы никогда ранее не применяли средств координации

  • Он не требует установки некоего центрального сервера, что означает, что демонстрации более сосредоточены на применении самого инструмента, вместо того, чтобы устанавливать его

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

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

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

Ansible

Как уже было отмечено, именно 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 развёртываться всего одной командой.

Установка Ansible

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


vagrant up ansible mon1 osd1
 	   

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


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

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

 

Рисунок 9



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

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

 

Рисунок 10



Создание вашего файла учёта ресурсов

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

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

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


$ ssh-keygen
 	   

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

 

Рисунок 11



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


$ ssh-copy-id mon1
 	   

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

 

Рисунок 12



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

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

 

Рисунок 13



Для возврата в свою ВМ 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, что позволяет вам перекрывать значения переменных либо на основании участия в хостах или группах соответственно. Для этого проделайте следующие шаги:

  1. Создайте некий каталог /etc/ansible/group_vars.

  2. В group_vars создайте некий файл с названием mons. В mons добавьте следующее:

    
    a_variable: "foo"
     	   
  3. В group_vars создайте некий файл с названием osds. В osds добавьте следующее:

    
    a_variable: "bar"
     	   

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

Тестирование

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

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

 

Рисунок 14



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


$ ansible mon1 -a 'uname -r'
 	   

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

 

Рисунок 15



Очень простой план

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


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

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


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

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

 

Рисунок 16



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

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


vagrant destroy --force
 	   

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

Добавление модулей Ansible Ceph

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


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

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

 

Рисунок 17



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

  • group_vars: мы уже обсуждали что здесь располагается и позже более подробно изучим все возможные опции настройки.

  • infrastructure-playbooks: Этот каталог содержит предварительно написанные планы (playbooks) для осуществления некоторых стандартных задач, таких как развёртывание кластера или добавления OSD в некий уже имеющийся. Имеющийся в верхней части каждого плана комментарий даёт хорошую идею о том, что он должен делать.

  • roles: Этот каталог содержит все роли, которые составляют все модули Ansible Ceph. Вы увидите, что для каждого из компонентов Ceph имеется некая роль и именно они вызываются через планы для установки, настройки и сопровождения Ceph.

Чтобы иметь возможность развернуть некий кластер 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 создать их для вас.

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

Развёртывание проверочного кластера при помощи Ansible

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

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

  1. Создайте некий файл с названием /etc/ansible/group_vars/ceph:

    
    ceph_origin: 'upstream'
    ceph_stable: true # use ceph stable branch
    ceph_stable_key: https://download.ceph.com/keys/release.asc
    ceph_stable_release: jewel # ceph stable release
    ceph_stable_repo: "http://download.ceph.com/debian-{{
    ceph_stable_release }}"monitor_interface: enp0s8 #Check ifconfig
    public_network: 192.168.0.0/24
    journal_size: 1024
     	   
  2. Создайте некий файл с названием /etc/ansible/group_vars/osds:

    
    devices:
    - /dev/sdb
    journal_collocation: true
     	   
  3. Создайте папку fetch и измените её владельца на своего пользователя vagrant:

    
    sudo mkdir /etc/ansible/fetch
    sudo chown vagrant /etc/ansible/fetch
     	   
  4. Выполните план развёртывания своего кластера Ceph:

    
    cd /etc/ansible
    sudo mv site.yml.sample site.yml
    ansible-playbook -K site.yml
     	   

    Параметр K сообщает Ansible что ему следует запросить у вас пароль для sudo.

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

 

Рисунок 18



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


vagrant@mon1:~$ sudo ceph -s:
 	   
 

Рисунок 19



И это завершает всё развёртывание полностью работающего кластера 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.