Thank you for reading this post, don't forget to subscribe!
1.Установка
2.Разносим данные по hdd и ssd в CEPH
3.Кеш на SSD в CEPH
Эволюция данной программно-определяемой системы хранения данных показывает неплохие темпы и результаты. Последняя версия данного ПО на текущий момент под названием Octopus хорошо подтянула веб интерфейс. Теперь через графическую панель можно выполнять большое количество задач, оговорюсь сразу, что далеко не все. Раньше веб интерфейс CEPH предоставлял гораздо меньше возможностей и практически все операции проводились через командную строку. Также в последней версии добавилась возможность инсталляции кластера с помощью утилиты cephadm, устанавливаемой на первую ноду создаваемой системы хранения. При этом сам основной функционал хранилища данных в программном продукте CEPH уже давно хорошо себя зарекомендовал.
Процесс установки
Самый простой способ установки кластера CEPH — использование ansible плейбука и ansible ролей от самих разработчиков софта — ceph-ansible. Для использования этого репозитария скачиваем его c github к себе на управляющий хост с помощью команды:
# git clone https://github.com/ceph/ceph-ansible |
После этого переходим в директорию с локальным репозитарием ceph-ansible. Нам нужно выбрать ветвь репозитария, в соответствии с которой будет происходить установка кластера. Так stable-5.0 используется для установки последнего стабильного на текущий момент релиза CEPH v15.x.x — Octopus. Чтобы выбрать эту версию выполняем следующую команду:
# git checkout stable-5.0 |
Далее необходимо проверить в файлике requirements.txt модули Python, которые должны быть установлены в системе на управляющем хосте, и установить их соответствующим образом. К примеру, это можно сделать с помощью команды pip.
# pip install -r requirements.txt |
Теперь необходимо настроить инвентарь Ansible в соответствии с запланированным функционалом каждого хоста в кластере CEPH. Допустим, в нашем примере мы будем использовать 3 сервера (192.168.1.101, 192.168.1.102, 192.168.1.103), на каждом из которых должны быть установлены сервисы MON, OSD, MGR, grafana-server. То есть, каждый сервер будет выполнять роль мониторинга кластера, иметь возможность подключать диски, а также обеспечивать интерфейс управления. Для этого в рабочей директории ceph-ansible создаем файлик inventory_hosts, в котором указываем следующее содержание.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
[mons] 192.168.1.101 192.168.1.102 192.168.1.103 [osds] 192.168.1.101 192.168.1.102 192.168.1.103 [mgrs] 192.168.1.101 192.168.1.102 192.168.1.103 [grafana-server] 192.168.1.101 192.168.1.102 192.168.1.103 |
Как Вы понимаете, чтобы плейбук успешно отработал на указанных хостах, на них должен присутствовать ssh rsa публичный ключ с управляющего хоста. Для этого необходимо скопировать этот ключик на эти сервера, если это еще не было сделано до этого.
После этого необходимо немного модернизировать файлы с переменными в подпапке group_vars. В нашем примере с учетом выбранных сервисов, которые будут задействованы в кластере, нам нужно провести следующие манипуляции.
# cp ./group_vars/all.yml.sample ./group_vars/all.yml # cp ./group_vars/mons.yml.sample ./group_vars/mons.yml # cp ./group_vars/osds.yml.sample ./group_vars/osds.yml |
Если в кластере CEPH будут реализованы дополнительно другие сервисы, то необходимо будет переименовать также и другие файлы с переменными.
Давайте посмотрим по нашему примеру значимое содержимое файлов с переменными. Так файл ./group_vars/all.yml выгляди следующим образом. В нашем случае мы используем одну подсеть 192.168.1.0/24 для удаленного доступа к хостам кластера, балансировки кластера и доступа к CEPH со стороны клиентов. Поэтому значения переменных monitor_address_block, public_network, cluster_network будут идентичными.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
--- grafana_server_group_name: grafana-server ceph_origin: repository ceph_repository: community ceph_stable_release: octopus generate_fsid: true monitor_address_block: 192.168.1.0/24 journal_size: 5120 # OSD journal size in MB public_network: 192.168.1.0/24 cluster_network: 192.168.1.0/24 dashboard_enabled: True dashboard_protocol: https dashboard_port: 8443 dashboard_admin_user: your_user dashboard_admin_password: your_password dashboard_crt: '' dashboard_key: '' grafana_admin_user: your_user grafana_admin_password: your_password |
Содержимое файла ./group_vars/mons.yml представлено ниже.
1 2 |
--- dummy: |
И содержание файла ./group_vars/osds.yml далее. В данном случае мы задействуем для хранения данных в кластере CEPH диски /dev/sdb и /dev/sdc на каждом из хостов.
1 2 3 4 5 6 |
--- dummy: devices: - /dev/sdb - /dev/sdc osd_auto_discovery: false |
Теперь осталось подработать сам ansible плейбук, который проводит саму установку CEPH. Для этого вначале копируем его из шаблона с помощью следующей команды:
# cp ./site.yml.sample ./site.yml |
После этого редактируем файл ./site.yml таким образом, чтобы он содержал только команды, релевантные сервисам CEPH, которые мы будем устанавливать. В данном случае это MON, OSD, MGR, grafana-server. Всю остальную информацию из файлика удаляем.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 |
--- # Defines deployment design and assigns role to server groups - hosts: - mons - osds - mgrs - grafana-server gather_facts: false any_errors_fatal: true become: true tags: always vars: delegate_facts_host: True pre_tasks: # If we can't get python2 installed before any module is used we will fail # so just try what we can to get it installed - import_tasks: raw_install_python.yml - name: gather facts setup: gather_subset: - 'all' - '!facter' - '!ohai' when: - not delegate_facts_host | bool or inventory_hostname in groups.get(client_group_name, []) - name: gather and delegate facts setup: gather_subset: - 'all' - '!facter' - '!ohai' delegate_to: "{{ item }}" delegate_facts: True with_items: "{{ groups['all'] | difference(groups.get('clients', [])) }}" run_once: true when: delegate_facts_host | bool tasks: - import_role: name: ceph-defaults - import_role: name: ceph-facts - import_role: name: ceph-validate - import_role: name: ceph-infra - import_role: name: ceph-common - hosts: mons gather_facts: false become: True any_errors_fatal: true pre_tasks: - name: set ceph monitor install 'In Progress' run_once: true set_stats: data: installer_phase_ceph_mon: status: "In Progress" start: "{{ lookup('pipe', 'date +%Y%m%d%H%M%SZ') }}" tasks: - import_role: name: ceph-defaults tags: ['ceph_update_config'] - import_role: name: ceph-facts tags: ['ceph_update_config'] - import_role: name: ceph-handler tags: ['ceph_update_config'] - import_role: name: ceph-config tags: ['ceph_update_config'] - import_role: name: ceph-mon - import_role: name: ceph-mgr when: groups.get(mgr_group_name, []) | length == 0 post_tasks: - name: set ceph monitor install 'Complete' run_once: true set_stats: data: installer_phase_ceph_mon: status: "Complete" end: "{{ lookup('pipe', 'date +%Y%m%d%H%M%SZ') }}" - hosts: mgrs gather_facts: false become: True any_errors_fatal: true pre_tasks: - name: set ceph manager install 'In Progress' run_once: true set_stats: data: installer_phase_ceph_mgr: status: "In Progress" start: "{{ lookup('pipe', 'date +%Y%m%d%H%M%SZ') }}" tasks: - import_role: name: ceph-defaults tags: ['ceph_update_config'] - import_role: name: ceph-facts tags: ['ceph_update_config'] - import_role: name: ceph-handler tags: ['ceph_update_config'] - import_role: name: ceph-config tags: ['ceph_update_config'] - import_role: name: ceph-mgr post_tasks: - name: set ceph manager install 'Complete' run_once: true set_stats: data: installer_phase_ceph_mgr: status: "Complete" end: "{{ lookup('pipe', 'date +%Y%m%d%H%M%SZ') }}" - hosts: osds gather_facts: false become: True any_errors_fatal: true pre_tasks: - name: set ceph osd install 'In Progress' run_once: true set_stats: data: installer_phase_ceph_osd: status: "In Progress" start: "{{ lookup('pipe', 'date +%Y%m%d%H%M%SZ') }}" tasks: - import_role: name: ceph-defaults tags: ['ceph_update_config'] - import_role: name: ceph-facts tags: ['ceph_update_config'] - import_role: name: ceph-handler tags: ['ceph_update_config'] - import_role: name: ceph-config tags: ['ceph_update_config'] - import_role: name: ceph-osd post_tasks: - name: set ceph osd install 'Complete' run_once: true set_stats: data: installer_phase_ceph_osd: status: "Complete" end: "{{ lookup('pipe', 'date +%Y%m%d%H%M%SZ') }}" - hosts: - mons - osds - mgrs gather_facts: false become: True any_errors_fatal: true tasks: - import_role: name: ceph-defaults - import_role: name: ceph-facts tasks_from: container_binary.yml - import_role: name: ceph-handler - import_role: name: ceph-crash - hosts: mons gather_facts: false become: True any_errors_fatal: true tasks: - import_role: name: ceph-defaults - name: get ceph status from the first monitor command: ceph --cluster {{ cluster }} -s register: ceph_status changed_when: false delegate_to: "{{ groups[mon_group_name][0] }}" run_once: true - name: "show ceph status for cluster {{ cluster }}" debug: msg: "{{ ceph_status.stdout_lines }}" delegate_to: "{{ groups[mon_group_name][0] }}" run_once: true when: - ceph_status is not skipped - ceph_status is successful |
Когда все подготовительные работы завершены, запускаем плейбук с помощью следующей команды и получаем в результате ее завершения работающий кластер CEPH. Время выполнения плейбука может быть порядка 10 — 20 минут.
# ansible-playbook ./site.yml -i ./inventory_hosts |
После успешного завершения отработки плейбука, можно начинать использовать CEPH либо через веб интерфейс, либо через CLI в SSH.
2. Разносим данные по hdd и ssd в CEPH
Кластер CEPH по умолчанию представляет собой один общий массив хранения данных, в котором объекты распределяются по всем имеющимся дискам в соответствии с их весом. Но зачастую этого бывает недостаточно. SSD диски уже давно не являются экзотикой, и используются на большинстве серверов, да и обычных десктопах и ноутбуках. Как распределить данные на кластере CEPH таким образом, чтобы SSD диски использовались строго для определенных категорий данных, а HDD для других категорий?
Настройка
Итак, у нас есть работающий кластер CEPH, на котором задействованы диски HDD и SSD под нужды хранения объектов OSD. Данные рекомендации актуальны для последней текущей на данный момент версии CEPH — Octopus. Веб интерфейс CEPH заметно подрос в возможностях за последнее время, но для конфигурации политик, которые позволят разносить данные, все равно придется использовать коммандную строку ceph.
По умолчанию в системе настроена одна crush политика — replicated_rule. Мы создадим еще две crush политики с помощью следующих команд.
# ceph osd crush rule create-replicated ssdrule default host ssd # ceph osd crush rule create-replicated hddrule default host hdd |
Первая политика по имени ssdrule задает правила хранения данных на SSD дисках, а вторая политика hddrule уже описывает использование шпиндельных дисков. В обоих случаях используется репликация для хранения данных и в качестве failure-domain хост кластера.
Чтобы посмотреть crush политики в кластере выполняем следующую команду. Так мы можем убедиться, что настроенные политики успешно видны в кластере.
# ceph osd crush rule ls replicated_rule ssdrule hddrule |
Теперь мы можем создавать пулы данных, указывая в настройках конкретную политику crush, исходя из которой будет выбираться тот или иной класс дисков, где будут храниться данные. Пример создания пулов в командной строке ceph показываю ниже. Оговорюсь сразу, что создание пулов и выбор нужной политики crush доступен и через веб интерфейс.
# ceph osd pool create ssdpool 32 32 ssdrule # ceph osd pool create hddpool 32 32 hddrule |
После этого нужные пулы созданы, мы их можем монтировать в нужной подсистеме CEPH и использовать по назначению.
3.Кеш на SSD в CEPH
Система хранения CEPH уже давно поддерживает функционал кеширования HDD пулов с помощью дисков SSD или NVMe. То есть, сами данные хранятся на массивах медленных HDD дисках, но при этом при оперативной записи/чтении могут использоваться намного более быстрые диски SSD/NVMe. Такой функционал считается одним из базовых в дорогих коммерческих стораджах middle-range уровня. В свое время долгое время занимался такого типа оборудованием. По своему опыту могу сказать, что такое кеширование является одним из важных моментов при выборе СХД в организации. Для Open Source продукта Ceph это важная фича, которая позволяет обеспечить нужную производительность общей системы при использовании шпиндельных дисков при необходимости.
Как настроить
Будем считать, что у нас уже есть готовый кластер CEPH версии 15 — Octopus, на котором настроены, как минимум, роли OSD, MON, MGR
В системе должны присутствовать 2 типа дисков — HDD и SSD. Первый тип дисков будет использоваться для хранения данных, а второй для кеширования. Как известно, по умолчанию CEPH пишет данные любого пула на все имеющиеся в наличии диски. Чтобы разнести данные по разным типам дисков, нужно настроить соответствующие CRUSH правила
Далее все манипуляции проводим в командной строке, в силу отсутствия соответствующего функционал в графическом интерфейсе.
Во-первых, необходимо все имеющиеся системные пулы на кластере CEPH перевести на использование HDD дисков. Для этого перенастраиваем CRUSH rule для каждого из пулов и ждем, когда произойдет ресинхронизация. Потери данных при этом не происходит. Пример такой команды для пула .rgw.root представлен ниже.
# ceph osd pool set .rgw.root crush_rule hddrule |
После завершения всех синхронизаций, данные на кластере будут распределены только по hdd дискам.
Во-вторых, необходимо создать CRUSH правило для распределения данных по ssd дискам для кеш слоя. Будем использовать тип правила — replicated rule. С помощью него все данные будут реплицироваться на 3 хоста нашего кластера. Пример команды для создания CRUSH rule под названием ssdrule для класса дисков ssd приведен ниже.
# ceph osd crush rule create-replicated ssdrule default host ssd |
В-третьих, создается пул, который будет выступать в качестве кеширующего слоя. Данный пул будет использовать строго быстрые ssd диски на кластере. Команда, которая выполняет создание такого пула под именем ssdcache приведена ниже.
# ceph osd pool create ssdcache 32 32 ssdrule |
В-четвертых, настраивается связка между основным пулом, на котором будут храниться данные и горячим пулом для кеширования. Допустим для нашего примера, что пул для хранения данных называется mypoolhdd. Его мы связываем с ssd пулом — ssdcache. В качестве режима работы кеширующего слоя выбирается — writeback. Это позволяет записывать данные на ssd диски и потом уже переносить информацию с них непосредственно на основной пул.
# ceph osd tier add mypoolhdd ssdcache # ceph osd tier cache-mode ssdcache writeback # ceph osd tier set-overlay mypoolhdd ssdcache |
В-пятых, для кеширующего слоя необходимо сконфигурировать параметры попадания в него. Прежде всего мы выбираем фильтр bloom, который будет использоваться для опредления попадания в кеширующий слой. Также указываем количественные параметры срабатывания кеша — hit_set_count и hit_set_period. Первый из них указывает сколько раз нужно обратиться к объекту, чтобы он попал в кеш, а второй показывает время жизни объекта в кеше.
# ceph osd pool set ssdcache hit_set_type bloom # ceph osd pool set ssdcache hit_set_count 6 # ceph osd pool set ssdcache hit_set_period 3600 |
В-шестых, настраиваем дополнительные параметры работы кеширующего слоя. Нам необходимо указать максимальный размер, который может быть помещен в горячий пул, количество объектов для кеширования, а также параметры сброса данных с ssd пула на обычный пул. Пример настройки приведен ниже.
# ceph osd pool set ssdcache target_max_bytes 1000000000000 # ceph osd pool set ssdcache target_max_objects 102400 # ceph osd pool set ssdcache cache_target_dirty_ratio 0.4 # ceph osd pool set ssdcache cache_target_dirty_high_ratio 0.6 # ceph osd pool set ssdcache cache_target_full_ratio 0.8 |
Есть и другие дополнительные параметры работы кеширования, которые могут быть сконфигурированы при желании. В общем случае нас устроят дефолтные настройки таких параметров, использующихся для этого на кластере.
На данном этапе создание тиринга для организация кеширующего слоя на базе ssd дисков завершено. Можно подключать основной hdd пул к выбранному CEPH клиенту и использовать его по назначению с увеличенной производительностью.