Глава 11. Настройка производительности и надёжности

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

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

Как мы уже изучали это в предыдущих главах, многие традиционные и коммерческие системы хранения выставляют производительность, которая ограничена отдельным интерфейсом SAS, Fiber Channel или сетевой среды. По мере масштабирования их производительности пропускная способность может оставаться постоянной или, в лучшем случае, расти с более медленной скоростью, чем имеющаяся у ёмкости. Среди прочих преимуществ Ceph имеется и возможность обходиться без точек дросселирования на уровне данных при одновременном масштабировании и ёмкости и пропускной способности по мере добавления узлов хранения и получения преимуществ улучшенных сетевых технологий.

Имеющееся ядро Linux приспосабливает ту систему, на которой оно работает, множеством различных способов, масштабируя буферы и пулы в соответствии с общим числом присутствующих ядер ЦПУ и предоставляемого объёма оперативной памяти. Однако, поскольку само ядро и прочие компоненты операционной системы должны использоваться как на тяжело загруженных оборудованием серверах, так и на скромных потребительских системах, имеются только те, которые доступны сразу после установки.

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

Многие установки ядра Linux настраиваются на постоянной основе через инфраструктуру sysctl при загрузках данной системы. Исторически добавления или изменения выполнялись внутри файла /etc/sysctl.conf, однако в современных дистрибутивах предлагается вместо этого применять во вклиниваемом каталоге /etc/sysctl.d. Мы можем собирать вместе относящиеся к различным группам установки в отдельные файлы, которыми может быть удобнее управлять по отдельности внутри данного каталога. В соответствии с соглашением, относящиеся к Ceph установки могут вводиться в некотором файле, именуемом как-то навроде /etc/sysctl.d/60-ceph.conf.

Ваше ядро Linux управляет традиционными процессами в виде потоков (threads) и имеет ограничение, которое устанавливает предел до какого численного значения может возрастать численный идентификатор потоков, а это косвенно ограничивает общее число одновременно присутствующих во всей системе в любой определённый момент времени. Данная установка pid_max устанавливается значением по умолчанию 32768 в ядре 3.19, некоторым значением, которого более чем достаточно для настольных систем, или систем,которые размещают приложения с обычной архитектурой. Демоны Ceph, однако, являются многопоточными и могут распространяться на тысячи потоков, в особенности, в периоды интенсивного восстановления. По мере того как кластеры становятся всё более крупными и всё более занятыми, узлы OSD со множеством работающих в них OSD могут легко превышать этот предел. Если журнальные записи вашего OSD или системы содержат сообщения подобные unable to fork or thread_create failed (отсутствует возможность ветвления или отказ thread_create), скорее всего произошло именно это.

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

kernel.pid_max = 4194303
 	   

Также это можно выполнить в состоянии исполнения:

$ echo 4194303 > /proc/sys/kernel/pid_max
		

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

Объем книги не даёт нам возможности подробно описывать всех настроек, но мы отметим здесь те, повышение значений которых также помогает избегать проблем создания потоков/ процессов.

kernel.threads-max=2097152
vm.max_map_count=524288
 	   

Загруженные FileStore OSD на базе XFS могут обнаружить, что эти установки оптимизируют производительность, в особенности если у вас имеется роскошь применения SSD. Операции синхронизации метаданных XFS обычно являются вторженческими и чем- то, доставляющим головную боль. Когда пробуждается определённый поток синхронизации, он может присвоить все записи всех прочих процессов (потоков), что может оказывать воздействие на журнал Ceph и сбросы данных. Именно в этом случае установки fs.xfs могут помочь смягчению такого эффекта.

Установки fs.aio-max-nr расширяют имеющуюся очередь дисковых операций. В диапазоне от самых умеренных до средних узлов OSD, скажем, таких, у которых менее 200 OSD, могут удовлетворяться теми значениями, которые установлены по умолчанию. По мере того, как возрастает плотность OSD в хосте, оно становится всё более ограничивающим фактором. Преимущества пропускной способности масштабирования данного значения пропорциональны количеству устройств; установка значения 50 миллионов должно оказаться достаточно просторным даже для самых загруженных узлов OSD Ceph.

fs.xfs.xfssyncd_centisecs=720000
fs.xfs.xfsbufd_centisecs=3000       # pre-4.0 kernels only
fs.xfs.age_buffer_centisecs=720000  # pre-4.0 kernels only
fs.aio-max-nr=50000000
 	   

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

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

По крайней мере, мы рекомендуем установить vm.min_free_kbytes в значение 1048576 или даже 2097152 , если только ваши системы не оснащены ограниченным объёмом памяти, а в таком случае вам на самом деле стоит задуматься о том, чтобы установить больше памяти. Современная оперативная память имеет доступные стоимости, в особенности на открытом рынке.

vm.min_free_kbytes=1048576
vm.vfs_cache_pressure=10
vm.zone_reclaim_mode=0
vm.dirty_ratio=80
vm.dirty_background_ratio=3
 	   

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

Мы уже упоминали ранее значение кадров Jumbo для увеличения производительности для увеличения эффективности сетевой среды и протокола. Обычно увеличенный размер MTU составляет 9000 байт; он должен быть настроен внутри вашей сетевой инфраструктуры, а также в настройках интерфейсов системы. В зависимости от вашего дистрибутива вы можете настроить его в /etc/network/interfaces, либо в относящихся к интерфейсу файлах, таких как /etc/sysconfig/network-scripts/ifcfg-eth0.

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

net.ipv4.tcp_timestamps=0
net.ipv4.tcp_sack=1
net.core.netdev_max_backlog=250000
net.ipv4.tcp_max_syn_backlog=100000
net.ipv4.tcp_max_tw_buckets=2000000
net.ipv4.tcp_tw_reuse=1
net.core.rmem_max=4194304
net.core.wmem_max=4194304
net.core.rmem_default=4194304
net.core.wmem_default=4194304
net.core.optmem_max=4194304
net.ipv4.tcp_rmem="4096 87380 4194304"
net.ipv4.tcp_wmem="4096 65536 4194304"
net.ipv4.tcp_low_latency=1
net.ipv4.tcp_adv_win_scale=1
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_no_metrics_save=1
net.ipv4.tcp_syncookies=0
net.core.somaxconn=5000
net.ipv4.tcp_ecn=0
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.all.accept_source_route=0
net.ipv4.icmp_echo_ignore_broadcasts=1
net.ipv4.tcp_no_metrics_save=1
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_fin_timeout=10
 	   

Эти модули ядра применяются для расширения сетевой безопасности путём реализации межсетевого экрана уровня ядра. Как и для прочих сторон самого ядра Linux, имеющиеся по умолчанию установки часто бывают недостаточными для загруженного кластера Ceph. Если политики вашей организации позволяют вам это, вы можете занести их все в чёрный список для предотвращения их применения при загрузке. Всё ещё имеет смысл поднять предельные значения в качестве альтернативы, так как даже поставленные в чёрный список модули могут выскользнуть обратно. Имеется таблица соединений, настраиваемая с помощью nf_conntrack, который по умолчанию может иметь значение всего 65536. Для узлов, размещающих 24 4 ТБ OSD мы предлагаем полмиллиона как достаточное значение. Очень плотные узлы могут потребовать даже ещё большее значение:

net.netfilter.nf_conntrack_max=524288
net.nf_conntrack_max=524288
 	   

Ваше ядро может применять одно или оба этих имени. Его повышение съест мегабайты дополнительной памяти ядра; для современных систем это элементарно.

Ниже приводится плейбук Ansible для выгрузки и удаления iptables и nf_conntrack вместе с их зависимостями.

# Выгрузка и установка в чёрный список модулей ядра, относящихся к iptables и nf_conntrack
# ref: https://goo.gl/aQFI8d
#
# Применение: ansible-playbook -e target=hostname rmmod.yml
# Для некоторых модулей допустимы отказы при удалении в случае, когда они не загружаются.
# Это игнорируется.
- name: ensure we are applying to ceph server nodes
  assert:
    that: "'ceph_mon' in group_names or 'ceph_osd' in group_names or 'ceph_rgw' in group_names or 'ceph_aio' in group_names"
- name: stop and disable iptables
  service:
    name: iptables
    enabled: no
    state: stopped
- name: remove nat, conntrack modules. order here is important.
  command: rmmod {{ item }}
  with_items:
    - iptable_nat- nf_nat_ipv4
    - nf_nat
    - nf_conntrack_ipv4
    - nf_defrag_ipv4
    - nf_conntrack_proto_gre
    - xt_CT
    - nf_conntrack
    - iptable_filter
    - iptable_raw
    - ip_tables
  ignore_errors: true
- name: do not load conntrack on boot
  file: path=/etc/sysconfig/modules/ip_conntrack.modules state=absent
- name: do not load conntrack_proto_gre on boot
  file: path=/etc/sysconfig/modules/nf_conntrack_proto_gre.modules state=absent
- name: blacklist the modules to ensure they are not loaded on reboot
  copy:
    owner: root
    mode: 0644
    dest: /etc/modprobe.d/conntrack.conf
    content: |
      blacklist nf_conntrack
      blacklist nf_conntrack_ipv6
      blacklist xt_conntrack
      blacklist nf_conntrack_ftp
      blacklist xt_state
      blacklist iptable_nat
      blacklist ipt_REDIRECT
      blacklist nf_nat
      blacklist nf_conntrack_ipv4
      blacklist nf_conntrack_proto_gre
      blacklist xt_CT
      blacklist iptable_raw
      blacklist ip_tables
 	   

Этот плейбук был разработан для систем RHEL7.2 с применением файла учёта (inventory) Ansible для конкретных определений групп хостов. Относительно практического использования на вашей площадке и для вашей версии ядра, он может потребовать настроек вашего файла учёта (inventory) и перечней модулей.

Всякий администратор Ceph (и каждый системный администратор) имеет некий набор предпочтительных настроек и подлежащих установке значений и имеются бесконечные споры о наилучшем практике применения. Сами названия и действия настроек, также как и их установки по умолчанию, меняются в зависимости от ядра и выпуска дистрибутива Linux. Те что представлены здесь основываются на нашем опыте. Ваши пройденные мили могут быть другими и мы предлагаем вам провести собственное изучение того, что подходит именно вам. В особенности богатой территорией для охоты являются архивы списков рассылки ceph-users.

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

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

Ранее в этой главе мы обсуждали испытывающие жажду в потоках демоны Ceph. В загруженных системах они также исчерпывают дескрипторы файлов (file handles). Надлежащий способ увеличения данного предела изменяется в зависимости от версии операционной системы и Ceph. Предлагаемым значением является минимум в 131072, а потенциально вплоть до 524288 в плотных, загруженных серверах. Последние версии Ceph позволяют нам устанавливать это значение в ceph.conf и поднимет его от вашего имени. Да, это некая настройка ОС, однако Ceph может теперь управлять ею для вас:

global]
max_open_files = 131072
 	   

Если ваша система имеет /etc/init/ceph-osd.conf, вы можете поднять это значение, которое может быть здесь очень маленьким, 32768. В прочих системах вам может потребоваться применить sysctl:

fs.file-max=524288
 	   

Среди из тех настроек Ceph, которые наиболее часто регулируются - те, которые ограничивают поведение обратной заливки и восстановления. Мы изучили их в Главе 6, Работа и сопровождение. Суммируем: это является компромиссом между скоростью восстановления жизнеспособности после сбоев и текущими операциями клиентов. Вплоть до выпуска Hammer LTS установленные по умолчанию значения были слишком агрессивными для многих оснащений, в особенности для тех, которые работали на относительно медленных жёстких дисках LFF с совместно размещаемыми журналами. Выпуск Jewel привнёс значительно более консервативные значения по умолчанию; если вы используете Jewel и последующие версии, вы можете обойтись без регулировок. Если вы применяете более раннюю версию, обратитесь ещё раз к Главе 6, Работа и сопровождение и рассмотрите их дросселирование на меньшие значения.

Имеется всего несколько настроек которыми можно регулировать OSD; оптимальные значения разнятся в зависимости от скоростей ваших OSD и устройств журнала, вашей рабочей нагрузки и доступного общего числа ядер ЦПУ. Все предложения здесь должны исследоваться и проверяться в контексте вашего уникального оснащения:

[osd]
filestore_queue_max_bytes = 1048576000
filestore_queue_max_ops = 50000
 	   

Приведённые выше установки хорошо работают у авторов с целью увеличения производительности OSD FileStore, развёрнутого на быстрых SSD. Ваш пробег может быть иным, в особенности для OSD на шпиндельных дисках.

osd]
osd_op_threads = 16
osd_disk_threads = 4
 	   

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

Мы также уже обсуждали установки выскребания в Главе 6, Работа и сопровождение; вы можете пожелать удлинения своих osd_deep_scrub_interval для минимизации раздоров, в особенности в системах со шпиндельными дисками.

В выпусках Ceph, начиная с Jewel, сами Мониторы выполняют достаточно хорошо задания по управлению своими базами данных. Это было не обязательно так в случае более ранних выпусков. Размер базы данных Монитора является функцией от общего числа OSD и PG в вашем кластере и того насколько часто перемешивается в нём топология. В течении процесса интенсивного восстановления или сопроводительных работ на узле имеющаяся база данных /var/lib/ceph/mon может возрастать до десятков ГБ. Это может становиться проблемой для систем, которые предоставляют скудное пространство файловой системы, а в некоторых случаях это может оказывать воздействие на способность к отклику Мониторов и тем самым к общему снижению мгновенности откликов кластера.

Даже для Jewel и последующих версий рекомендуются эти установки; они направляют демонов Мониторов на зачистку несвежих записей из их баз данных в момент запуска:

[mon]
mon_compact_on_start = true
 	   

Другой полезной установкой является mon_osd_down_out_subtree_limit. Она оказывает воздействие на то как ведёт себя Ceph при отключении компонентов:

[mon]
mon_osd_down_out_subtree_limit = host
 	   

Его поведение, как и само название, оказывается хитроумным. Это значение определяется как самый маленький тип сегмента (bucket) CRUSH, который не будет автоматически помечаться выведенными (out). Это означает, что если всё относящееся к расположенному в этом сегменте CRUSH указанного типа отказывает за раз, эти элементы не будут иметь применённого к ним состояния выведенных (out). При установленном по умолчанию значению rack, сегменты host и OSD будут помечаться как выведенные (out) если они входят в состояние отключённых (down) из- за отказа и данный кластер и данный кластер начнёт восстановление чтобы гарантировать установленную политику репликаций.

Если мы изменяем это значение на host, это означает, что если целый узел OSD внезапно надышится пылью, Ceph не пометит его OSD отключёнными (down). Когда у нас имеется некий кластер с репликациями и областью отказа установленной на rack, такая утрата некоего хоста целиком за раз больше не будет включать восстановление. Основная идея состоит в том, что по большей части некий хост может быть быстро возвращён в строй, скажем, путём аппаратного сброса, поскольку его переклинило во время перезагрузки. Или, возможно, мы установили плохое ядро, которое следует удалить перед второй перезагрузкой.

Если же хост на самом деле умер, тогда у нас имеется возможность выполнить обратную заливку/ восстановление по своему собственному усмотрению, с установленной собственноручно скоростью, скажем, при помощи сценария ceph-gentle-reweight, который мы применяли в Главе 6, Работа и сопровождение.

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

Доступны и многие другие установки, которые могут принести пользу вашей оснастке. Они также могут и утащить вас в преисподнюю. В данном втором издании "Изучаем Ceph" мы придерживаемся консервативного подхода. Мы не хотим перегружать вас массой установок с которыми вы можете чувствовать себя неудобно и которые могут оказаться не верными для вашего уникального собрания оборудования, версий и вариантов применения. Когда вы ознакомитесь с компонентами Ceph и имеющейся в вашем кластере динамикой, мы предлагаем вам ознакомиться с подробностями более широкого набора установок на http://docs.ceph.com и в перечне архивов почтовой рассылки ceph-users.

Служба блочных устройств RBD Ceph интенсивно используется облачными платформами, такими как OpenStack и прочие решения виртуализации. Эффективное кэширование в оперативной памяти на самой стороне клиента может значительно улучшать ту производительность, на которую рассчитывают пользователи:

[client.yourclientname]
rbd_cache = true
rbd_cache_size = 67108864
rbd_cache_max_dirty = 50331648
rbd_cache_target_dirty = 33554432
 	   

Эти значения 64 МБ, 48 МБ и 32 МБ удваивают имеющиеся по умолчанию численные значения для Luminous.

Некоторые рекомендации предполагают большие значения, однако рассматривают эти буферы кэширования выделенными для каждого подключаемого тома. Рассмотрим некий плотный узел гипервизора, размещающего 100 экземпляров ВМ меньшего размера, причём каждой соответствует некий том RBD для её загрузочного диска. С такими значениями сам узел гипервизора выделит более 6 ГБ оперативной памяти только для кэшировния гостевых загрузочных дисков. Вы можете иметь возможность сэкономить здесь, но гипревизоры зачастую ограничены в оперативной памяти и это необходимо тщательно рассматривать в контексте общего бюджета и настроек ёмкости памяти сервера для планирования.

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

Для применения встроенного инструмента Ceph вначале давайте создадим некий выделенный, одноразовый пул для работы с ним. Для того чтобы быть узаконенным тестом, он должен иметь те же самые атрибуты, что и ваш промышленный пул: число Групп размещения, множитель репликаций, правила CRUSH и так далее.

Параметры тестирования rados включают в свой состав:

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

# rados bench -p data 60 write
Maintaining 16 concurrent writes of 4194304 bytes for up to 60 seconds or 0 objects
Object prefix: benchmark_data_ncc_1701
sec Cur ops started finished avg MB/s cur MB/s last lat avg lat
0 0 0 0 0 0 - 0
1 16 39 23 92.9777 93 0.627 0.56
2 16 67 50 98.853 109 0.523 0.59
3 16 97 80 105.234 119 0.267 0.55
4 16 126 109 107.843 114 0.231 0.54
5 16 152 135 106.111 103 0.301 0.52
6 16 181 164 108.334 114 0.714 0.56
7 16 209 192 108.945 110 0.843 0.59
8 16 237 220 108.238 111 0.133 0.53
9 16 266 249 109.934 113 0.780 0.53
10 15 292 276 109.364 111 0.822 0.51
...
		

Тест следует исполнить множество раз и на протяжении длительного периода времени и сравнивать результаты для их усреднения чтобы подтвердить данную методику.

Ceph Benchmarking Tool представляет собой сложное поведение тестирования, которое может применять множество методов сбора данных. Наши возможности не позволяют предоставить полное его изучение в данной книге. Те, кто заинтересован с серьёзных повторяемых количественных данных, например, в тестировании различных профилей установок EC или FileStore найдут его неоценимым.

Отыскать CBT можно по ссылке https://github.com/ceph/cbt.

Flexible I/O Tester это то, о чём говорят: инструмент с большими возможностями настройки для тестирования различных систем хранения. Многие дистрибутивы предоставляют упакованными пакеты fio для упрощения установки.

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

Заполнение тома, затем последовательные записи 1M на протяжении 96 часов без проверки чтением

[global]
ioengine=libaio
direct=1
group_reporting
filename=/dev/sda
[sequential-fill]
description=Sequential fill phase
rw=write
iodepth=16
bs=4M
random-write-steady]
stonewall
description=Random write steady state phase
rw=randwrite
bs=1M
iodepth=32
numjobs=4
time_based
runtime=345600
write_bw_log=fio-write-bw
write_lat_log=fio-write-lat
write_iops_log=fio-write-iops
log_avg_msec=1000
 	   

Заполнение тома, с последующей записью небольших блоков на протяжении 96 часов без проверки чтением

[global]
ioengine=libaio
direct=1
group_reporting
filename=/dev/sda[sequential-fill]
description=Sequential fill phase
rw=write
iodepth=16
bs=4M
[random-write-steady]
stonewall
description=Random write steady state phase
rw=randwrite
bssplit=512b/10:1k/3:2k/3:4k/45:8k/15:16k/7:32k/5:64k/5:128k/7
time_based
runtime=345600
iodepth=32
numjobs=4
write_bw_log=fio-write-bw
write_lat_log=fio-write-lat
write_iops_log=fio-write-iops
log_avg_msec=1000
 	   

Заполнение тома и случайные 4k записи на протяжении 96 с возможной проверкой чтением

[global]
ioengine=libaio
direct=1group_reporting
filename=/dev/sda
[sequential-fill]
description=Sequential fill phase
rw=write
iodepth=16
bs=4M
[random-write-steady]
stonewall
description=Random write steady state with verification
rw=randwrite
bssplit=512b/10:4k/80:64k/5:1M/5
time_based
runtime=345600
iodepth=32
numjobs=4
write_bw_log=fio-write-bw
write_lat_log=fio-write-lat
write_iops_log=fio-write-iops
log_avg_msec=1000
verify=crc32c-intel
verify_dump=1
verify_backlog=1000000
 	   

Изучение не завершается на этом; ни для вас, ни для ваших скромных авторов. Ряд компаний в сообществе Ceph предлагает интерактивные классы и профессиональные услуги. Темы Ceph популярны на конференциях, включая происходящие два раза в год OpenStack Summits. Как мы уже упоминали в Главе 2, Компоненты и службы Ceph, имеющееся сообщество является неотъемлемой частью развития Ceph. Сами авторы являются разработчиками кода, поэтому мы призываем вас приложить к этому и ваши усилия!

Ого! Мы прошли одиннадцать заполненных действием глав, изучающих концептуальные и практические стороны планирования, оснащения и управления кластерами Ceph. Мы надеемся, что данное второе издание "Изучаем Ceph" поможет вам в проектировании, реализации и управлении офигенного распределённого хранилища.