Pagpili sa CEPH. Bahin 1
Kami adunay lima ka racks, napulo ka optical switch, gi-configure ang BGP, usa ka dosena nga mga SSD ug usa ka hugpong sa mga SAS disk sa tanan nga mga kolor ug gidak-on, ingon man ang proxmox ug ang tinguha nga ibutang ang tanan nga static nga datos sa among kaugalingon nga pagtipig sa S3. Dili nga kini tanan gikinahanglan alang sa virtualization, apan sa higayon nga magsugod ka sa paggamit sa opensource, dayon sunda ang imong kalingawan hangtod sa katapusan. Ang nakasamok lang nako kay BGP. Walay usa sa kalibutan nga mas walay mahimo, iresponsable ug imoral kay sa internal nga BGP routing. Ug nahibal-an ko nga sa dili madugay kami mosalom niini.
Ang tahas gamay ra - adunay CEPH, apan dili kini maayo. Gikinahanglan ang pagbuhat og "maayo".
Ang cluster nga akong nadawat kay heterogeneous, dali nga gitono ug halos wala gitono. Kini naglangkob sa duha ka grupo sa lain-laing mga node, uban sa usa ka komon nga grid nga naglihok ingon nga usa ka cluster ug sa usa ka publiko nga network. Ang mga node napuno sa upat ka matang sa mga disk - duha ka matang sa SSD, nga nakolekta sa duha ka managlahing mga lagda sa pagbutang, ug duha ka matang sa HDD nga lainlaig gidak-on, nga nakolekta sa ikatulo nga grupo. Ang problema sa lain-laing mga gidak-on nasulbad pinaagi sa lain-laing OSD gibug-aton.
Ang setup mismo gibahin sa duha ka bahin - pag-tune sa operating system и tuning sa CEPH mismo ug ang mga setting niini.
Pag-upgrade sa OS
network
Ang taas nga latency nakaapekto sa pagrekord ug pagbalanse. Kung nagrekord - tungod kay ang kliyente dili makadawat usa ka tubag bahin sa malampuson nga pagrekord hangtod ang mga replika sa datos sa ubang mga grupo sa pagbutang nagpamatuod sa kalampusan. Tungod kay ang mga lagda alang sa pag-apod-apod sa mga replika sa CRUSH nga mapa usa ka replika sa matag host, ang network kanunay nga gigamit.
Busa, ang unang butang nga akong nakahukom nga buhaton mao ang gamay nga tweak sa kasamtangan nga network, samtang sa samang higayon naningkamot sa pagkombinsir kanako sa pagbalhin ngadto sa lain nga network.
Sa pagsugod, gi-tweak nako ang mga setting sa mga network card. Nagsugod ko pinaagi sa pag-set up sa mga pila:
Unsay nahitabo:
ethtool -l ens1f1
root@ceph01:~# ethtool -l ens1f1
Channel parameters for ens1f1:
Pre-set maximums:
RX: 0
TX: 0
Other: 1
Combined: 63
Current hardware settings:
RX: 0
TX: 0
Other: 1
Combined: 1
root@ceph01:~# ethtool -g ens1f1
Ring parameters for ens1f1:
Pre-set maximums:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Current hardware settings:
RX: 256
RX Mini: 0
RX Jumbo: 0
TX: 256
root@ceph01:~# ethtool -l ens1f1
Channel parameters for ens1f1:
Pre-set maximums:
RX: 0
TX: 0
Other: 1
Combined: 63
Current hardware settings:
RX: 0
TX: 0
Other: 1
Combined: 1Makita nga ang kasamtangan nga mga parameter layo sa maximum. Nadugangan:
root@ceph01:~#ethtool -G ens1f0 rx 4096
root@ceph01:~#ethtool -G ens1f0 tx 4096
root@ceph01:~#ethtool -L ens1f0 combined 63Gigiyahan sa usa ka maayo kaayo nga artikulo
nagdugang sa gitas-on sa pagpadala nga pila txqueuelen gikan sa 1000 ngadto sa 10
root@ceph01:~#ip link set ens1f0 txqueuelen 10000Aw, pagsunod sa dokumentasyon ni ceph mismo
nadugangan MTU sa 9000.
root@ceph01:~#ip link set dev ens1f0 mtu 9000Gidugang sa /etc/network/interfaces aron ang tanan sa ibabaw makarga sa pagsugod
cat / etc / network / interface
root@ceph01:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto ens1f0
iface ens1f0 inet manual
post-up /sbin/ethtool -G ens1f0 rx 4096
post-up /sbin/ethtool -G ens1f0 tx 4096
post-up /sbin/ethtool -L ens1f0 combined 63
post-up /sbin/ip link set ens1f0 txqueuelen 10000
mtu 9000
auto ens1f1
iface ens1f1 inet manual
post-up /sbin/ethtool -G ens1f1 rx 4096
post-up /sbin/ethtool -G ens1f1 tx 4096
post-up /sbin/ethtool -L ens1f1 combined 63
post-up /sbin/ip link set ens1f1 txqueuelen 10000
mtu 9000Pagkahuman niana, pagkahuman sa parehas nga artikulo, gisugdan nako nga mahunahunaon nga iliko ang mga gunitanan sa 4.15 kernel. Gikonsiderar nga ang mga node adunay 128G RAM, natapos namon ang usa ka file sa pag-configure alang sa sysctl
iring /etc/sysctl.d/50-ceph.conf
net.core.rmem_max = 56623104
#Максимальный размер буфера приема данных для всех соединений 54M
net.core.wmem_max = 56623104
#Максимальный размер буфера передачи данных для всех соединений 54M
net.core.rmem_default = 56623104
#Размер буфера приема данных по умолчанию для всех соединений. 54M
net.core.wmem_default = 56623104
#Размер буфера передачи данных по умолчанию для всех соединений 54M
# на каждый сокет
net.ipv4.tcp_rmem = 4096 87380 56623104
#Векторная (минимум, по умолчанию, максимум) переменная в файле tcp_rmem
# содержит 3 целых числа, определяющих размер приемного буфера сокетов TCP.
# Минимум: каждый сокет TCP имеет право использовать эту память по
# факту своего создания. Возможность использования такого буфера
# гарантируется даже при достижении порога ограничения (moderate memory pressure).
# Размер минимального буфера по умолчанию составляет 8 Кбайт (8192).
#Значение по умолчанию: количество памяти, допустимое для буфера
# передачи сокета TCP по умолчанию. Это значение применяется взамен
# параметра /proc/sys/net/core/rmem_default, используемого другими протоколами.
# Значение используемого по умолчанию буфера обычно (по умолчанию)
# составляет 87830 байт. Это определяет размер окна 65535 с
# заданным по умолчанию значением tcp_adv_win_scale и tcp_app_win = 0,
# несколько меньший, нежели определяет принятое по умолчанию значение tcp_app_win.
# Максимум: максимальный размер буфера, который может быть автоматически
# выделен для приема сокету TCP. Это значение не отменяет максимума,
# заданного в файле /proc/sys/net/core/rmem_max. При «статическом»
# выделении памяти с помощью SO_RCVBUF этот параметр не имеет значения.
net.ipv4.tcp_wmem = 4096 65536 56623104
net.core.somaxconn = 5000
# Максимальное число открытых сокетов, ждущих соединения.
net.ipv4.tcp_timestamps=1
# Разрешает использование временных меток (timestamps), в соответствии с RFC 1323.
net.ipv4.tcp_sack=1
# Разрешить выборочные подтверждения протокола TCP
net.core.netdev_max_backlog=5000 (дефолт 1000)
# максимальное количество пакетов в очереди на обработку, если
# интерфейс получает пакеты быстрее, чем ядро может их обработать.
net.ipv4.tcp_max_tw_buckets=262144
# Максимальное число сокетов, находящихся в состоянии TIME-WAIT одновременно.
# При превышении этого порога – «лишний» сокет разрушается и пишется
# сообщение в системный журнал.
net.ipv4.tcp_tw_reuse=1
#Разрешаем повторное использование TIME-WAIT сокетов в случаях,
# если протокол считает это безопасным.
net.core.optmem_max=4194304
#Увеличить максимальный общий буфер-космической ALLOCATABLE
#измеряется в единицах страниц (4096 байт)
net.ipv4.tcp_low_latency=1
#Разрешает стеку TCP/IP отдавать предпочтение низкому времени ожидания
# перед более высокой пропускной способностью.
net.ipv4.tcp_adv_win_scale=1
# Эта переменная влияет на вычисление объема памяти в буфере сокета,
# выделяемой под размер TCP-окна и под буфер приложения.
# Если величина tcp_adv_win_scale отрицательная, то для вычисления размера
# используется следующее выражение:
# Bytes- bytes2в степени -tcp_adv_win_scale
# Где bytes – это размер окна в байтах. Если величина tcp_adv_win_scale
# положительная, то для определения размера используется следующее выражение:
# Bytes- bytes2в степени tcp_adv_win_scale
# Переменная принимает целое значение. Значение по-умолчанию – 2,
# т.е. под буфер приложения отводится ¼ часть объема, определяемого переменной
# tcp_rmem.
net.ipv4.tcp_slow_start_after_idle=0
# механизм перезапуска медленного старта, который сбрасывает значение окна
# перегрузки, если соединение не использовалось заданный период времени.
# Лучше отключить SSR на сервере, чтобы улучшить производительность
# долгоживущих соединений.
net.ipv4.tcp_no_metrics_save=1
#Не сохранять результаты измерений TCP соединения в кеше при его закрытии.
net.ipv4.tcp_syncookies=0
#Отключить механизм отправки syncookie
net.ipv4.tcp_ecn=0
#Explicit Congestion Notification (Явное Уведомление о Перегруженности) в
# TCP-соединениях. Используется для уведомления о возникновении «затора»
# на маршруте к заданному хосту или сети. Может использоваться для извещения
# хоста-отправителя о необходимости снизить скорость передачи пакетов через
# конкретный маршрутизатор или брандмауэр.
net.ipv4.conf.all.send_redirects=0
# выключает выдачу ICMP Redirect … другим хостам. Эта опция обязательно
# должна быть включена, если хост выступает в роли маршрутизатора любого рода.
# У нас нет маршрутизации.
net.ipv4.ip_forward=0
#Сопсно отключение форвардинга. Мы не шлюз, докер на машинах не поднят,
# нам это не нужно.
net.ipv4.icmp_echo_ignore_broadcasts=1
#Не отвечаем на ICMP ECHO запросы, переданные широковещательными пакетами
net.ipv4.tcp_fin_timeout=10
#определяет время сохранения сокета в состоянии FIN-WAIT-2 после его
# закрытия локальной стороной. Дефолт 60
net.core.netdev_budget=600 # (дефолт 300)
# Если выполнение программных прерываний не выполняются достаточно долго,
# то темп роста входящих данных может превысить возможность ядра
# опустошить буфер. В результате буферы NIC переполнятся, и трафик будет потерян.
# Иногда, необходимо увеличить длительность работы SoftIRQs
# (программных прерываний) с CPU. За это отвечает netdev_budget.
# Значение по умолчанию 300. Параметр заставит процесс SoftIRQ обработать
# 300 пакетов от NIC перед тем как отпустить CPU
net.ipv4.tcp_fastopen=3
# TFO TCP Fast Open
# если и клиент и сервер имеют поддержку TFO, о которой сообщают за счет
# специального флага в TCP пакете. В нашем случае является плацебо, просто
# выглядит красиво)Сluster nga network gigahin sa bulag nga 10Gbps nga mga interface sa network ngadto sa usa ka bulag nga patag nga network. Ang matag makina nasangkapan sa dual-port network card mellanox 10/25 Gbps, gisaksak sa duha ka separado nga 10Gbps switch. Ang aggregation gihimo gamit ang OSPF, tungod kay ang bonding sa lacp sa pipila ka rason nagpakita sa kinatibuk-ang throughput nga maximum nga 16 Gbps, samtang ang ospf malampusong migamit sa duha ka napulo sa matag makina. Ang umaabot nga mga plano mao ang pagpahimulos sa ROCE sa kini nga mga melanox aron makunhuran ang latency. Giunsa pag-set up kini nga bahin sa network:
- Tungod kay ang mga makina mismo adunay mga eksternal nga IP address sa BGP, kinahanglan namon ang software - (mas tukma, sa panahon sa pagsulat niini nga artikulo mao kini ) nagtindog na.
- Sa kinatibuk-an, ang mga makina adunay duha ka mga interface sa network, ang matag usa adunay duha ka mga interface - usa ka total nga 4 nga mga pantalan. Ang usa ka network card mitan-aw sa pabrika nga adunay duha ka mga pantalan ug ang BGP gi-configure niini, ang ikaduha nagtan-aw sa duha ka lain-laing mga switch nga adunay duha ka mga pantalan ug ang OSPF gibutang niini.
Dugang nga mga detalye sa pag-set up sa OSPF: Ang nag-unang tahas mao ang pag-aggregate sa duha ka mga link ug adunay fault tolerance.
duha ka interface sa network ang gi-configure sa duha ka yano nga patag nga network - 10.10.10.0/24 ug 10.10.20.0/24
1: ens1f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
inet 10.10.10.2/24 brd 10.10.10.255 scope global ens1f0
2: ens1f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
inet 10.10.20.2/24 brd 10.10.20.255 scope global ens1f1diin ang mga sakyanan magkita sa usag usa.
disk
Ang sunod nga lakang mao ang pag-optimize sa mga disk. Alang sa SSD giusab nako ang scheduler sa noop, alang sa HDD - Deadline. Sa prangka nga pagkasulti, ang NOOP nagtrabaho sa prinsipyo sa "first in, first out," nga sa English morag "FIFO (First In, First Out)." Ang mga hangyo gipila sa ilang pag-abot. Ang DEADLINE labi nga gipunting sa pagbasa, dugang ang proseso nga nakapila nakakuha hapit eksklusibo nga pag-access sa disk sa panahon sa operasyon. Kini perpekto alang sa among sistema - pagkahuman, usa ra ka proseso ang molihok sa matag disk - OSD daemon.
(Kadtong gustong mo-dive sa I/O scheduler makabasa bahin niini dinhi:
Kadtong gusto nga magbasa sa Russian: )
Sa mga rekomendasyon alang sa pag-tune sa Linux, girekomenda usab nga dugangan ang nr_request
nr_hangyo
Ang bili sa nr_requests nagtino sa gidaghanon sa I/O nga mga hangyo nga ma-buffer sa dili pa ang I/O scheduler magpadala/makadawat ug data sa block device, kon ikaw naggamit ug RAID card/Block Device nga makadumala sa mas dako nga pila kay sa unsa ang I Ang /O scheduler gitakda, ang pagpataas sa bili sa nr_requests mahimong makatabang sa pag-uswag sa tibuok ug pagpakunhod sa load sa server kung daghang I/O ang mahitabo sa server. Kung gigamit nimo ang Deadline o CFQ isip scheduler, gisugyot nga imong ibutang ang nr_request nga bili ngadto sa 2 ka pilo sa bili sa giladmon sa pila.
PERO! Ang mga lungsuranon mismo, ang mga nag-develop sa CEPH, nagkumbinser kanato nga ang ilang sistema sa mga prayoridad mas maayo
WBThrottle ug/o nr_requests
WBThrottle ug/o nr_requests
Ang pagtipig sa file naggamit og buffered I/O alang sa pagsulat; kini nagdala sa usa ka gidaghanon sa mga benepisyo kon ang file storage log anaa sa mas paspas nga media. Gipahibalo ang mga hangyo sa kliyente sa diha nga ang data masulat sa log, ug dayon i-flush sa data disk mismo sa ulahi gamit ang standard nga Linux functionality. Kini nagpaposible sa mga spindle OSD nga maghatag ug write latency nga susama sa SSDs sa pagsulat sa gagmay nga mga pagbuto. Kining nalangan nga pagsulat balik usab nagtugot sa kernel mismo sa pag-organisar pag-usab sa mga hangyo sa I/O sa disk, uban ang paglaom nga mahiusa sila o tugotan ang kasamtangan nga mga disk head sa pagpili sa mas maayo nga agianan sa ilang mga platter. Ang net nga epekto mao nga mahimo nimong ipislit ang gamay nga I/O gikan sa matag disk kaysa mahimo sa direkta o kadungan nga I/O.
Bisan pa, ang usa ka piho nga problema motungha kung ang gidaghanon sa umaabot nga mga rekord sa usa ka gihatag nga cluster sa Ceph molapas sa tanan nga mga kapabilidad sa nagpahiping mga disk. Niini nga senaryo, ang kinatibuk-ang gidaghanon sa mga pending nga operasyon sa I/O nga naghulat nga masulat sa disk mahimong motubo nga dili mapugngan ug moresulta sa I/O nga mga pila nga mopuno sa tibuok disk ug Ceph queues. Ang mga hangyo sa pagbasa labi nga naapektuhan tungod kay natanggong sila taliwala sa mga hangyo sa pagsulat, nga mahimo’g pila ka segundo aron ma-flush sa panguna nga disk.
Aron mabuntog kini nga problema, si Ceph adunay writeback throttling nga mekanismo nga gitukod sa file storage nga gitawag og WBThrottle. Gidisenyo kini aron limitahan ang kinatibuk-ang gidaghanon sa tapolan nga pagsulat sa I/O nga mahimong magpila ug magsugod sa proseso sa pag-flush sa sayo pa kaysa natural nga mahitabo tungod sa pagpaandar sa kernel mismo. Ikasubo, gipakita sa pagsulay nga ang mga default nga kantidad mahimo’g dili pa makunhuran ang naglungtad nga pamatasan sa usa ka lebel nga makapakunhod sa kini nga epekto sa latency sa pagbasa. Ang mga pag-adjust makapausab niini nga kinaiya ug makapakunhod sa kinatibuk-ang gitas-on sa pila sa pagsulat ug makahimo niini nga epekto nga dili kaayo grabe. Adunay usa ka trade-off, bisan pa: pinaagi sa pagkunhod sa kinatibuk-ang maximum nga gidaghanon sa mga entry nga gitugotan nga mapila, mahimo nimong makunhuran ang abilidad sa kernel mismo aron mapataas ang kahusayan niini sa pag-order sa umaabot nga mga hangyo. Angayan nga hunahunaon og gamay kung unsa ang imong gikinahanglan alang sa imong piho nga kaso sa paggamit, mga workloads ug pag-adjust aron mohaum niini.
Aron makontrol ang giladmon sa maong write-backlog queue, mahimo nimong pakunhuran ang kinatibuk-ang maximum nga gidaghanon sa outstanding I/O operations gamit ang WBThrottle settings, o mahimo nimong pakunhuran ang maximum value para sa outstanding operations sa block level sa imong kernel mismo. Ang duha epektibo nga makakontrol sa parehas nga pamatasan, ug ang imong mga gusto mao ang basehan sa pagpatuman niini nga setting.
Kinahanglan usab nga hinumdoman nga ang sistema sa prayoridad sa operasyon ni Ceph mas episyente alang sa mas mubu nga mga pangutana sa lebel sa disk. Pinaagi sa pagkunhod sa kinatibuk-ang pila ngadto sa usa ka disk, ang nag-unang lokasyon sa pila mobalhin ngadto sa Ceph, diin kini adunay labaw nga kontrol sa unsa nga prayoridad ang operasyon sa I/O. Tagda ang mosunod nga pananglitan:
echo 8 > /sys/block/sda/queue/nr_requestsKOMON
Ug pipila pa nga mga pag-tweak sa kernel aron mahimo ang imong awto nga humok ug seda ug pug-on ang gamay nga pasundayag gikan sa hardware
iring /etc/sysctl.d/60-ceph2.conf
kernel.pid_max = 4194303
#Дисков в каждой машине по 25, потому рассчитывали что процессов будет много
kernel.threads-max=2097152
# Тредов, естессно, тоже.
vm.max_map_count=524288
# Увеличили количество областей карты памяти процесса.
# Как следует из документации по ядерным переменным
# Области карты памяти используется как побочный эффект вызова
# malloc, напрямую с помощью mmap, mprotect и madvise, а также при загрузке
# общих библиотек.
fs.aio-max-nr=50000000
# Подтюним параметры input-output
# Ядро Linux предоставляет функцию асинхронного неблокирующего ввода-вывода (AIO),
# которая позволяет процессу инициировать несколько операций ввода-вывода
# одновременно, не дожидаясь завершения какой-либо из них.
# Это помогает повысить производительность приложений,
# которые могут перекрывать обработку и ввод-вывод.
# Параметр aio-max-nr определяет максимальное количество допустимых
# одновременных запросов.
vm.min_free_kbytes=1048576
# минимальный размер свободной памяти который необходимо поддерживать.
# Выставлен 1Gb, чего вполне достаточно для работы операционной системы,
# и позволяет избегать OOM Killer для процессов OSD. Хотя памяти и так
# как у дурака фантиков, но запас карман не тянет
vm.swappiness=10
# Говорим использовать своп если осталось свободным 10% памяти.
# На машинах 128G оперативы, и 10% это 12 Гигов. Более чем достаточно для работы.
# Штатный параметр в 60% заставлял тормозить систему, залезая в своп,
# когда есть еще куча свободной памяти
vm.vfs_cache_pressure=1000
# Увеличиваем со штатных 100. Заставляем ядро активнее выгружать
# неиспользуемые страницы памяти из кеша.
vm.zone_reclaim_mode=0
# Позволяет устанавливать более или менее агрессивные подходы к
# восстановлению памяти, когда в зоне заканчивается память.
# Если он установлен на ноль, то не происходит восстановление зоны.
# Для файловых серверов или рабочих нагрузок
# выгодно, если их данные кэшированы, zone_reclaim_mode
# оставить отключенным, поскольку эффект кэширования,
# вероятно, будет более важным, чем местонахождение данных.
vm.dirty_ratio=20
# Процент оперативной памяти, который можно выделить под "грязные" страницы
# Вычисляли из примерного расчета:
# В система 128 гигов памяти.
# Примерно по 20 дисков SSD, у которых в настройках CEPH указано
# выделять под кэширование по 3G оперативы.
# Примерно по 40 дисков HDD, для которых этот параметр равен 1G
# 20% от 128 это 25.6 гигов. Итого, в случае максимальной утилизации памяти,
# для системы останется 2.4G памяти. Чего ей должно хватить чтоб выжить и дождаться
# стука копыт кавалерии - то есть пришествия DevOps который все починит.
vm.dirty_background_ratio=3
# процент системной памяти, который можно заполнить dirty pages до того,
# как фоновые процессы pdflush/flush/kdmflush запишут их на диск
fs.file-max=524288
# Ну и открытых файлов у нас,вероятно, будет сильно больше, чем указано по дефолту. Pagpaunlod sa CEPH
Mga setting nga gusto nakong hisgotan sa mas detalyado:
iring /etc/ceph/ceph.conf
osd:
journal_aio: true # Три параметра, включающие
journal_block_align: true # прямой i/o
journal_dio: true # на журнал
journal_max_write_bytes: 1073714824 # Немного растянем максимальный размер
# разово записываемой операции в журнал
journal_max_write_entries: 10000 # Ну и количество одновременных записей
journal_queue_max_bytes: 10485760000
journal_queue_max_ops: 50000
rocksdb_separate_wal_dir: true # Решили делать отдельный wal
# Даже попытались выбить под это дело
# NVMe
bluestore_block_db_create: true # Ну и под журнал отдельное устройство
bluestore_block_db_size: '5368709120 #5G'
bluestore_block_wal_create: true
bluestore_block_wal_size: '1073741824 #1G'
bluestore_cache_size_hdd: '3221225472 # 3G'
# большой объем оперативы позволяет
# хранить достаточно большие объемы
bluestore_cache_size_ssd: '9663676416 # 9G'
keyring: /var/lib/ceph/osd/ceph-$id/keyring
osd_client_message_size_cap: '1073741824 #1G'
osd_disk_thread_ioprio_class: idle
osd_disk_thread_ioprio_priority: 7
osd_disk_threads: 2 # количество тредов у демона на один диск
osd_failsafe_full_ratio: 0.95
osd_heartbeat_grace: 5
osd_heartbeat_interval: 3
osd_map_dedup: true
osd_max_backfills: 2 # количество одновременных операций заполнения на один ОСД.
osd_max_write_size: 256
osd_mon_heartbeat_interval: 5
osd_op_threads: 16
osd_op_num_threads_per_shard: 1
osd_op_num_threads_per_shard_hdd: 2
osd_op_num_threads_per_shard_ssd: 2
osd_pool_default_min_size: 1 # Особенности жадности. Очень быстро стало
osd_pool_default_size: 2 # нехватать места, потому как временное
# решение приняли уменьшение количество
# реплик данных
osd_recovery_delay_start: 10.000000
osd_recovery_max_active: 2
osd_recovery_max_chunk: 1048576
osd_recovery_max_single_start: 3
osd_recovery_op_priority: 1
osd_recovery_priority: 1 # параметр регулируем по необходимости на ходу
osd_recovery_sleep: 2
osd_scrub_chunk_max: 4Ang pipila sa mga parameter nga gisulayan alang sa QA sa bersyon 12.2.12 nawala sa ceph nga bersyon 12.2.2, pananglitan osd_recovery_threads. Busa, ang mga plano naglakip sa usa ka update sa produksyon ngadto sa 12.2.12. Ang praktis nagpakita sa pagkaangay tali sa mga bersyon 12.2.2 ug 12.2.12 sa usa ka cluster, nga nagtugot sa rolling updates.
Test cluster
Siyempre, alang sa pagsulay gikinahanglan nga adunay parehas nga bersyon sama sa gubat, apan sa panahon nga nagsugod ako sa pagtrabaho sa cluster, ang mas bag-o lamang ang anaa sa repositoryo. Sa pagtan-aw, unsa ang imong mahibal-an sa menor de edad nga bersyon dili kaayo dako (1393 linya sa configs batok 1436 sa bag-ong bersyon), nakahukom kami nga magsugod sa pagsulay sa bag-o (pag-update gihapon, nganong moadto sa daan nga basura)
Ang bugtong butang nga among gisulayan nga biyaan ang daan nga bersyon mao ang pakete ceph-deploy tungod kay ang pipila sa mga utilities (ug pipila sa mga empleyado) gipahaum sa syntax niini. Ang bag-ong bersyon lahi kaayo, apan wala makaapekto sa operasyon sa cluster mismo, ug kini nahabilin sa bersyon 1.5.39
Tungod kay ang ceph-disk command tin-aw nga nag-ingon nga kini wala na gigamit ug gigamit ang ceph-volume nga sugo, mga minahal, nagsugod kami sa paghimo og mga OSD uban niini nga sugo, nga walay pag-usik sa panahon sa mga karaan na.
Ang plano mao ang paghimo og salamin sa duha ka SSD drive diin atong ibutang ang OSD logs, nga, sa baylo, nahimutang sa spindle SASs. Niining paagiha mapanalipdan nato ang atong kaugalingon gikan sa mga problema sa datos kon ang disk nga adunay log mahulog.
Nagsugod kami sa paghimo og cluster sumala sa dokumentasyon
iring /etc/ceph/ceph.conf
root@ceph01-qa:~# cat /etc/ceph/ceph.conf # положили заранее подготовленный конфиг
[client]
rbd_cache = true
rbd_cache_max_dirty = 50331648
rbd_cache_max_dirty_age = 2
rbd_cache_size = 67108864
rbd_cache_target_dirty = 33554432
rbd_cache_writethrough_until_flush = true
rbd_concurrent_management_ops = 10
rbd_default_format = 2
[global]
auth_client_required = cephx
auth_cluster_required = cephx
auth_service_required = cephx
cluster network = 10.10.10.0/24
debug_asok = 0/0
debug_auth = 0/0
debug_buffer = 0/0
debug_client = 0/0
debug_context = 0/0
debug_crush = 0/0
debug_filer = 0/0
debug_filestore = 0/0
debug_finisher = 0/0
debug_heartbeatmap = 0/0
debug_journal = 0/0
debug_journaler = 0/0
debug_lockdep = 0/0
debug_mon = 0/0
debug_monc = 0/0
debug_ms = 0/0
debug_objclass = 0/0
debug_objectcatcher = 0/0
debug_objecter = 0/0
debug_optracker = 0/0
debug_osd = 0/0
debug_paxos = 0/0
debug_perfcounter = 0/0
debug_rados = 0/0
debug_rbd = 0/0
debug_rgw = 0/0
debug_throttle = 0/0
debug_timer = 0/0
debug_tp = 0/0
fsid = d0000000d-4000-4b00-b00b-0123qwe123qwf9
mon_host = ceph01-q, ceph02-q, ceph03-q
mon_initial_members = ceph01-q, ceph02-q, ceph03-q
public network = 8.8.8.8/28 # адрес изменен, естественно ))
rgw_dns_name = s3-qa.mycompany.ru # и этот адрес измен
rgw_host = s3-qa.mycompany.ru # и этот тоже
[mon]
mon allow pool delete = true
mon_max_pg_per_osd = 300 # больше трехсот плейсмент групп
# на диск не решились
# хотя параметр, естественно, зависит от количества пулов,
# их размеров и количества OSD. Иметь мало но здоровых PG
# тоже не лучший выбор - страдает точность балансировки
mon_osd_backfillfull_ratio = 0.9
mon_osd_down_out_interval = 5
mon_osd_full_ratio = 0.95 # пока для SSD дисков местом для их
# журнала является тот-же девайс что и для ОСД
# решили что 5% от диска (который сам размером 1.2Tb)
# должно вполне хватить, и коррелирует с параметром
# bluestore_block_db_size плюс вариативность на большие
# плейсмент группы
mon_osd_nearfull_ratio = 0.9
mon_pg_warn_max_per_osd = 520
[osd]
bluestore_block_db_create = true
bluestore_block_db_size = 5368709120 #5G
bluestore_block_wal_create = true
bluestore_block_wal_size = 1073741824 #1G
bluestore_cache_size_hdd = 3221225472 # 3G
bluestore_cache_size_ssd = 9663676416 # 9G
journal_aio = true
journal_block_align = true
journal_dio = true
journal_max_write_bytes = 1073714824
journal_max_write_entries = 10000
journal_queue_max_bytes = 10485760000
journal_queue_max_ops = 50000
keyring = /var/lib/ceph/osd/ceph-$id/keyring
osd_client_message_size_cap = 1073741824 #1G
osd_disk_thread_ioprio_class = idle
osd_disk_thread_ioprio_priority = 7
osd_disk_threads = 2
osd_failsafe_full_ratio = 0.95
osd_heartbeat_grace = 5
osd_heartbeat_interval = 3
osd_map_dedup = true
osd_max_backfills = 4
osd_max_write_size = 256
osd_mon_heartbeat_interval = 5
osd_op_num_threads_per_shard = 1
osd_op_num_threads_per_shard_hdd = 2
osd_op_num_threads_per_shard_ssd = 2
osd_op_threads = 16
osd_pool_default_min_size = 1
osd_pool_default_size = 2
osd_recovery_delay_start = 10.0
osd_recovery_max_active = 1
osd_recovery_max_chunk = 1048576
osd_recovery_max_single_start = 3
osd_recovery_op_priority = 1
osd_recovery_priority = 1
osd_recovery_sleep = 2
osd_scrub_chunk_max = 4
osd_scrub_chunk_min = 2
osd_scrub_sleep = 0.1
rocksdb_separate_wal_dir = true# создаем мониторы
root@ceph01-qa:~#ceph-deploy mon create ceph01-q
# генерируем ключи для аутентификации нод в кластере
root@ceph01-qa:~#ceph-deploy gatherkeys ceph01-q
# Это если поштучно. Если у нас несколько машин доступны - те, которые описаны в конфиге в секции
# mon_initial_members = ceph01-q, ceph02-q, ceph03-q
# можно запустить эти две команды в виде одной
root@ceph01-qa:~#ceph-deploy mon create-initial
# Положим ключи в указанные в конфиге места
root@ceph01-qa:~#cat ceph.bootstrap-osd.keyring > /var/lib/ceph/bootstrap-osd/ceph.keyring
root@ceph01-qa:~#cat ceph.bootstrap-mgr.keyring > /var/lib/ceph/bootstrap-mgr/ceph.keyring
root@ceph01-qa:~#cat ceph.bootstrap-rgw.keyring > /var/lib/ceph/bootstrap-rgw/ceph.keyring
# создадим ключ для управления кластером
root@ceph01-qa:~#ceph-deploy admin ceph01-q
# и менеджер, плагинами управлять
root@ceph01-qa:~#ceph-deploy mgr create ceph01-qAng una nga butang nga akong napandol sa dihang nagtrabaho uban niini nga bersyon sa ceph-deploy nga adunay usa ka cluster nga bersyon 12.2.12 usa ka sayup sa dihang misulay sa paghimo og OSD nga adunay db sa usa ka software raid -
root@ceph01-qa:~#ceph-volume lvm create --bluestore --data /dev/sde --block.db /dev/md0
blkid could not detect a PARTUUID for device: /dev/md1Sa tinuud, ang blkid dili ingon PARTUUID, mao nga kinahanglan nako nga maghimo mga partisyon nga mano-mano:
root@ceph01-qa:~#parted /dev/md0 mklabel GPT
# разделов будет много,
# без GPT их создать не получится
# размер раздела мы указали в конфиге выше = bluestore_block_db_size: '5368709120 #5G'
# Дисков у меня 20 под OSD, руками создавать разделы лень
# потому сделал цикл
root@ceph01-qa:~#for i in {1..20}; do echo -e "nnnn+5Gnw" | fdisk /dev/md0; doneAng tanan daw andam na, naningkamot kami sa paghimo sa OSD pag-usab ug sa pagkuha sa mosunod nga sayop (nga, sa dalan, wala gikopya sa gubat)
sa paghimo sa usa ka OSD nga tipo nga bluestore nga wala ipiho ang agianan sa WAL, apan gipiho ang db
root@ceph01-qa:~#ceph-volume lvm create --bluestore --data /dev/sde --block.db /dev/md0
stderr: 2019-04-12 10:39:27.211242 7eff461b6e00 -1 bluestore(/var/lib/ceph/osd/ceph-0/) _read_fsid unparsable uuid
stderr: 2019-04-12 10:39:27.213185 7eff461b6e00 -1 bdev(0x55824c273680 /var/lib/ceph/osd/ceph-0//block.wal) open open got: (22) Invalid argument
stderr: 2019-04-12 10:39:27.213201 7eff461b6e00 -1 bluestore(/var/lib/ceph/osd/ceph-0/) _open_db add block device(/var/lib/ceph/osd/ceph-0//block.wal) returned: (22) Invalid argument
stderr: 2019-04-12 10:39:27.999039 7eff461b6e00 -1 bluestore(/var/lib/ceph/osd/ceph-0/) mkfs failed, (22) Invalid argument
stderr: 2019-04-12 10:39:27.999057 7eff461b6e00 -1 OSD::mkfs: ObjectStore::mkfs failed with error (22) Invalid argument
stderr: 2019-04-12 10:39:27.999141 7eff461b6e00 -1 ** ERROR: error creating empty object store in /var/lib/ceph/osd/ceph-0/: (22) Invalid argumenDugang pa, kung sa parehas nga salamin (o sa lain nga lugar, nga imong gusto) maghimo ka usa ka partisyon alang sa WAL ug ipiho kini sa paghimo sa OSD, nan ang tanan hapsay (gawas sa hitsura sa usa ka bulag nga WAL, nga dili nimo mahimo. gusto).
Apan, tungod kay anaa pa kini sa layo nga mga plano sa pagbalhin sa WAL ngadto sa NVMe, ang praktis wala nahimong sobra.
root@ceph01-qa:~#ceph-volume lvm create --bluestore --data /dev/sdf --block.wal /dev/md0p2 --block.db /dev/md1p2Naghimo mga monitor, managers ug OSD. Karon gusto nako nga igrupo sila nga lahi, tungod kay nagplano ako nga adunay lainlaing mga lahi sa mga disk - paspas nga mga pool sa SSD ug dako, apan hinay nga mga pool sa SAS pancake.
Ibutang ta nga ang mga server adunay 20 ka mga disk, ang una nga napulo usa ka tipo, ang ikaduha lain.
Ang inisyal, default, nga kard ingon niini:
ceph osd nga kahoy
gamut@ceph01-q:~# kahoy nga ceph osd
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 14.54799 gamut default
-3 9.09200 host ceph01-q
0 ssd 1.00000 osd.0 pataas 1.00000 1.00000
1 ssd 1.00000 osd.1 pataas 1.00000 1.00000
2 ssd 1.00000 osd.2 pataas 1.00000 1.00000
3 ssd 1.00000 osd.3 pataas 1.00000 1.00000
4 hdd 1.00000 osd.4 pataas 1.00000 1.00000
5 hdd 0.27299 osd.5 pataas 1.00000 1.00000
6 hdd 0.27299 osd.6 pataas 1.00000 1.00000
7 hdd 0.27299 osd.7 pataas 1.00000 1.00000
8 hdd 0.27299 osd.8 pataas 1.00000 1.00000
9 hdd 0.27299 osd.9 pataas 1.00000 1.00000
10 hdd 0.27299 osd.10 pataas 1.00000 1.00000
11 hdd 0.27299 osd.11 pataas 1.00000 1.00000
12 hdd 0.27299 osd.12 pataas 1.00000 1.00000
13 hdd 0.27299 osd.13 pataas 1.00000 1.00000
14 hdd 0.27299 osd.14 pataas 1.00000 1.00000
15 hdd 0.27299 osd.15 pataas 1.00000 1.00000
16 hdd 0.27299 osd.16 pataas 1.00000 1.00000
17 hdd 0.27299 osd.17 pataas 1.00000 1.00000
18 hdd 0.27299 osd.18 pataas 1.00000 1.00000
19 hdd 0.27299 osd.19 pataas 1.00000 1.00000
-5 5.45599 host ceph02-q
20 ssd 0.27299 osd.20 pataas 1.00000 1.00000
21 ssd 0.27299 osd.21 pataas 1.00000 1.00000
22 ssd 0.27299 osd.22 pataas 1.00000 1.00000
23 ssd 0.27299 osd.23 pataas 1.00000 1.00000
24 hdd 0.27299 osd.24 pataas 1.00000 1.00000
25 hdd 0.27299 osd.25 pataas 1.00000 1.00000
26 hdd 0.27299 osd.26 pataas 1.00000 1.00000
27 hdd 0.27299 osd.27 pataas 1.00000 1.00000
28 hdd 0.27299 osd.28 pataas 1.00000 1.00000
29 hdd 0.27299 osd.29 pataas 1.00000 1.00000
30 hdd 0.27299 osd.30 pataas 1.00000 1.00000
31 hdd 0.27299 osd.31 pataas 1.00000 1.00000
32 hdd 0.27299 osd.32 pataas 1.00000 1.00000
33 hdd 0.27299 osd.33 pataas 1.00000 1.00000
34 hdd 0.27299 osd.34 pataas 1.00000 1.00000
35 hdd 0.27299 osd.35 pataas 1.00000 1.00000
36 hdd 0.27299 osd.36 pataas 1.00000 1.00000
37 hdd 0.27299 osd.37 pataas 1.00000 1.00000
38 hdd 0.27299 osd.38 pataas 1.00000 1.00000
39 hdd 0.27299 osd.39 pataas 1.00000 1.00000
-7 6.08690 host ceph03-q
40 ssd 0.27299 osd.40 pataas 1.00000 1.00000
41 ssd 0.27299 osd.41 pataas 1.00000 1.00000
42 ssd 0.27299 osd.42 pataas 1.00000 1.00000
43 ssd 0.27299 osd.43 pataas 1.00000 1.00000
44 hdd 0.27299 osd.44 pataas 1.00000 1.00000
45 hdd 0.27299 osd.45 pataas 1.00000 1.00000
46 hdd 0.27299 osd.46 pataas 1.00000 1.00000
47 hdd 0.27299 osd.47 pataas 1.00000 1.00000
48 hdd 0.27299 osd.48 pataas 1.00000 1.00000
49 hdd 0.27299 osd.49 pataas 1.00000 1.00000
50 hdd 0.27299 osd.50 pataas 1.00000 1.00000
51 hdd 0.27299 osd.51 pataas 1.00000 1.00000
52 hdd 0.27299 osd.52 pataas 1.00000 1.00000
53 hdd 0.27299 osd.53 pataas 1.00000 1.00000
54 hdd 0.27299 osd.54 pataas 1.00000 1.00000
55 hdd 0.27299 osd.55 pataas 1.00000 1.00000
56 hdd 0.27299 osd.56 pataas 1.00000 1.00000
57 hdd 0.27299 osd.57 pataas 1.00000 1.00000
58 hdd 0.27299 osd.58 pataas 1.00000 1.00000
59 hdd 0.89999 osd.59 pataas 1.00000 1.00000
Himoon nato ang atong kaugalingong mga virtual racks ug server nga adunay blackjack ug uban pang mga butang:
root@ceph01-q:~#ceph osd crush add-bucket rack01 root #создали новый root
root@ceph01-q:~#ceph osd crush add-bucket ceph01-q host #создали новый хост
root@ceph01-q:~#ceph osd crush move ceph01-q root=rack01 #переставили сервер в другую стойку
root@ceph01-q:~#osd crush add 28 1.0 host=ceph02-q # Добавили ОСД в сервер
# Если криво создали то можно удалить
root@ceph01-q:~# ceph osd crush remove osd.4
root@ceph01-q:~# ceph osd crush remove rack01Ang mga problema nga among nasugatan sa panagsangka cluster, kung mosulay sa paghimo og bag-ong host ug ibalhin kini sa usa ka kasamtangan nga rack - command ceph osd crush lihok ceph01-host root=rack01 nagyelo, ug ang mga monitor nagsugod sa pagkahulog sa usag usa. Ang pag-abort sa command gamit ang yano nga CTRL+C mibalik sa cluster sa kalibutan sa mga buhi.
Usa ka pagpangita nagpakita niini nga problema:
Ang solusyon mao ang paglabay sa crushmap ug tangtangon ang seksyon gikan didto lagda replicated_ruleset
root@ceph01-prod:~#ceph osd getcrushmap -o crushmap.row #Дампим карту в сыром виде
root@ceph01-prod:~#crushtool -d crushmap.row -o crushmap.txt #переводим в читаемый
root@ceph01-prod:~#vim crushmap.txt #редактируем, удаляя rule replicated_ruleset
root@ceph01-prod:~#crushtool -c crushmap.txt -o new_crushmap.row #компилируем обратно
root@ceph01-prod:~#ceph osd setcrushmap -i new_crushmap.row #загружаем в кластерAkhtung: Kini nga operasyon mahimong hinungdan sa pagbalanse sa grupo sa pagbutang tali sa mga OSD. Kini ang hinungdan niini alang kanamo, apan gamay ra.
Ug ang katingad-an nga butang nga among nasugatan sa test cluster mao nga pagkahuman sa pag-reboot sa OSD server, nakalimot sila nga gibalhin sila sa bag-ong mga server ug racks, ug mibalik sa default nga gamut.
Ingon usa ka sangputanan, pagkahuman natipon ang katapusan nga laraw diin naghimo kami usa ka lahi nga gamut alang sa mga ssd drive ug usa ka lahi alang sa mga spindle drive, gikuha namon ang tanan nga mga OSD sa mga rack ug gitangtang ra ang default nga gamut. Pagkahuman sa pag-reboot, ang OSD nagsugod sa pagpabilin sa lugar.
Pagkahuman sa pagkalot sa dokumentasyon sa ulahi, nakit-an namon ang usa ka parameter nga responsable sa kini nga pamatasan. Mahitungod kaniya sa ikaduhang bahin
Giunsa namo paghimo ang lainlaing mga grupo pinaagi sa tipo sa disk.
Sa pagsugod, naghimo kami og duha ka mga ugat - alang sa ssd ug alang sa hdd
root@ceph01-q:~#ceph osd crush add-bucket ssd-root root
root@ceph01-q:~#ceph osd crush add-bucket hdd-root rootTungod kay ang mga server pisikal nga nahimutang sa lain-laing mga racks, alang sa kasayon naghimo kami og mga racks nga adunay mga server niini
# Стойки:
root@ceph01-q:~#ceph osd crush add-bucket ssd-rack01 rack
root@ceph01-q:~#ceph osd crush add-bucket ssd-rack02 rack
root@ceph01-q:~#ceph osd crush add-bucket ssd-rack03 rack
root@ceph01-q:~#ceph osd crush add-bucket hdd-rack01 rack
root@ceph01-q:~#ceph osd crush add-bucket hdd-rack01 rack
root@ceph01-q:~#ceph osd crush add-bucket hdd-rack01 rack
# Сервера
root@ceph01-q:~#ceph osd crush add-bucket ssd-ceph01-q host
root@ceph01-q:~#ceph osd crush add-bucket ssd-ceph02-q host
root@ceph01-q:~#ceph osd crush add-bucket ssd-ceph03-q host
root@ceph01-q:~#ceph osd crush add-bucket hdd-ceph01-q host
root@ceph01-q:~#ceph osd crush add-bucket hdd-ceph02-q host
root@ceph01-q:~#ceph osd crush add-bucket hdd-ceph02-q hostug giapod-apod ang mga disk sumala sa ilang mga tipo sa lainlaing mga server
root@ceph01-q:~# Диски с 0 по 3 это SSD, находятся в ceph01-q, ставим их в сервер
root@ceph01-q:~# ssd-ceph01-q
root@ceph01-q:~#ceph osd crush add 0 1 host=ssd-ceph01-q
root@ceph01-q:~#ceph osd crush add 1 1 host=ssd-ceph01-q
root@ceph01-q:~#ceph osd crush add 2 1 host=ssd-ceph01-q
root@ceph01-q:~#ceph osd crush add 3 1 host=ssd-ceph01-q
root-ceph01-q:~# аналогично с другими серверамиAng pagkatag sa mga disk taliwala sa mga ruta sa ssd-root ug hdd-root, gibiyaan namon nga walay sulod ang root-default, aron mapapas namo kini
root-ceph01-q:~#ceph osd crush remove defaultSunod, kinahanglan namon nga maghimo mga lagda sa pag-apod-apod nga among igapos sa mga pool nga gihimo - sa mga lagda among ipasabut kung unsang mga ugat ang makabutang sa among data sa pool ug ang lebel sa pagkatalagsaon sa replika - pananglitan, ang mga replika kinahanglan naa sa lainlaing mga server, o sa lainlaing mga racks (mahimo nimo bisan sa lainlaing mga ugat, kung kami adunay ingon nga pag-apod-apod)
Sa wala pa magpili usa ka tipo, mas maayo nga basahon ang dokumentasyon:
root-ceph01-q:~#ceph osd crush rule create-simple rule-ssd ssd-root host firstn
root-ceph01-q:~#ceph osd crush rule create-simple rule-hdd hdd-root host firstn
root-ceph01-q:~# Мы указали два правила, в которых данные реплицируются
root-ceph01-q:~# между хостами - то есть реплика должна лежать на другом хосте,
root-ceph01-q:~# даже если они в одной стойке
root-ceph01-q:~# В продакшене, если есть возможность, лучше распределить хосты
root-ceph01-q:~# по стойкам и указать распределять реплики по стойкам:
root-ceph01-q:~# ##ceph osd crush rule create-simple rule-ssd ssd-root rack firstnAw, naghimo kami mga pool diin gusto namon nga tipigan ang mga imahe sa disk sa among virtualization sa umaabot - PROXMOX:
root-ceph01-q:~# #ceph osd pool create {NAME} {pg_num} {pgp_num}
root-ceph01-q:~# ceph osd pool create ssd_pool 1024 1024
root-ceph01-q:~# ceph osd pool create hdd_pool 1024 1024Ug gisultihan namon kini nga mga pool kung unsang mga lagda sa pagbutang ang gamiton
root-ceph01-q:~#ceph osd crush rule ls # смотрим список правил
root-ceph01-q:~#ceph osd crush rule dump rule-ssd | grep rule_id #выбираем ID нужного
root-ceph01-q:~#ceph osd pool set ssd_pool crush_rule 2
Ang pagpili sa gidaghanon sa mga placement nga grupo kinahanglan nga duolon uban sa usa ka nag-una nga panan-awon alang sa imong cluster - gibana-bana nga pila ka mga OSD ang anaa didto, unsa nga gidaghanon sa mga datos (ingon nga usa ka porsyento sa kinatibuk-ang gidaghanon) ang anaa sa pool, unsa ang ang kinatibuk-ang kantidad sa datos.
Sa kinatibuk-an, gitambagan nga dili adunay labaw pa sa 300 nga mga grupo sa pagbutang sa disk, ug mas dali ang pagbalanse sa gagmay nga mga grupo sa pagbutang - kana, kung ang imong tibuuk nga pool adunay 10 Tb ug adunay 10 PG sa sulod niini - unya pagbalanse pinaagi sa paglabay sa terabyte nga mga tisa (pg) mahimong suliran - ibubo ang balas nga adunay gamay nga gidak-on nga mga lugas sa balas ngadto sa mga balde nga mas sayon ug mas parehas).
Apan kinahanglan natong hinumdoman nga kung mas daghan ang gidaghanon sa mga PG, mas daghang mga kahinguhaan ang gigasto sa pagkalkulo sa ilang lokasyon - ang memorya ug ang CPU nagsugod sa paggamit.
Ang usa ka mahait nga pagsabut mahimo , nga gihatag sa mga nag-develop sa dokumentasyon sa CEPH.
Listahan sa mga materyales:
Source: www.habr.com