Как мы строили S3 хранилище DataLine. Эксперименты, тестирование и немного о бегемотах

Снова привет, на связи Алексей Приставко, и это вторая часть моего рассказа об объектном S3 хранилище DataLine на базе Cloudian HyperStore.

Сегодня я подробно расскажу о том, как устроено наше S3 хранилище и с какими трудностями мы столкнулись в процессе его создания. Обязательно коснемся «железной» темы и разберем оборудование, на котором мы в итоге остановились.

Поехали!

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

Итоговая схема физического оборудования

Так как далее речь пойдет о наших «муках выбора», сразу же приведу итоговый список железа, к которому мы пришли. Небольшой дисклеймер: выбор сетевого оборудования был во многом обусловлен его наличием на нашем (между прочим, весьма добротном) складе.

Итак, на физическом уровне хранилища мы имеем следующее оборудование:

Наименование	Функция	Конфигурация	Кол-во
Сервер Lenovo System x3650 M5	Рабочая нода	1x Xeon E5-2630v4 2.2GHz, 4x 16GB  DDR4, 14x 10TB 7.2K 6Gbps SATA 3.5", 2x  480GB SSD, Intel x520 Dual Port 10GbE SFP+, 2x750W HS PSU	4
Сервер  HP ProLiant DL360 G9	Нода балансировщика нагрузки	2  E5-2620 v3, 128G RAM, 2 600GB SSD, 4 SAS HDD, Intel x520 Dual Port 10GbE SFP+	2
Коммутатор Cisco C4500	Border Gateway	Catalyst WS-C4500X-16SFP+	2
Коммутатор Cisco C3750	Порт-экстендер	Catalyst WS-C3750X-24T with C3KX-NM-10G	2
Коммутатор Cisco C2960	control plane	Catalyst WS-C2960+48PST-L	1

Для лучшего понимания архитектуры, мы по очереди разберем все элементы и поговорим об их особенностях и задачах.

Начнем с серверов. Серверы Lenovo имеют специальную конфигурацию, выполненную совместно и в полном соответствии с рекомендациями и спецификациями Cloudian. К примеру, в них используется контроллер с функцией прямого доступа к дискам. Так как в нашем случае RAID организуется на уровне прикладного ПО, такой режим повышает надежность и ускоряет работу дисковой подсистемы. Точно такие же серверы можно приобрести в качестве Cloudian Appliance вместе со всеми лицензиями.

Серверы-балансировщики нагрузки с Nginx под CentOS гарантируют равномерное распределение нагрузки на рабочие ноды и абстрагируют пользователя от внутренней организации трафика. А в качестве приятного бонуса — при необходимости на них можно будет организовать кэш.

Пара Cisco 4500X на шестнадцать 10GB SFP+ выполняет роль ядра и бордера нашей маленькой, но гордой сети хранилища. Конечно, железо немного старомодно, но не уступает «новому» в надежности, имеет внутреннее резервирование, а его функционал удовлетворяет всем нашим требованиям. C3750 играют роль фабрик-экстендера, незачем 1G трансиверы в 10G слоты пихать. А переходить полностью на 10GB линки также большого смысла пока нет. Как показали тесты, в процессор и диски мы упираемся раньше.

Схема ниже достаточно подробно иллюстрирует описанную мной физическую организацию:

1. Схема физической организации хранилища

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

Идем ниже по схеме. Обе пары Cisco (4500/4500, 3750/3750) объединены в единые логические устройства с помощью стека и VSS. Стек собран двумя стек-кабелями, VSS через три 10G оптических линка. Это позволяет добиться того, что оба устройства в каждой паре взаимодействуют как единое целое. Такая кластеризация позволяет нам работать в рамках одного прозрачного L2-сегмента через оба устройства пары и сделать общую агрегацию линков с помощью LACP, так как эта технология нативно поддерживается как ОС серверов, так и Cisco IOS. Со стороны сервера это выглядит так, будто он работает с одним свитчом вместо двух, и выше в приложении доступен агрегированный канал двойной ёмкости.

Вся коммутация сетевого оборудования между собой и на входящие каналы выполнена с помощью оптических 10G линков, серверное оборудование подключается при помощи 10G Twinax кабелей Cisco и 1G медью.

Для отказоустойчивости на входящем канале используется BGP, для балансировки между внешними IP-адресами — Round Robin DNS. Сами внешние адреса запаркованы на серверах-балансировщиках нагрузки и в случае необходимости мигрируют между нодами с помощью связки Pacemaker/Corosync.

Мониторинг и управление по IPMI осуществляется по прямому внутреннему линку. Все менеджмент-интерфейсы (как серверов, так и Cisco) подключены через отдельные свитчи control plane. Они же, в свою очередь, включены в сеть управления ЦОД. Это гарантирует нам невозможность потери связи с оборудованием в ходе работ или в результате аварии на внешней сети. На самый крайний случай есть дежурные с KVM.

Логическая сеть

Чтобы понять, как устроена логическая сеть S3 хранилища DataLine, обратимся к еще одной схеме:

2. Схема логической сети хранилища

Как видно, логика сети состоит из нескольких сегментов.

Внешняя сеть (Q) общей ёмкостью 20G подсоединена напрямую к Provider Edge. Далее следуют Cisco 4500 и балансировщики.

Следующий логический блок (X) — VLAN между балансировщиками и рабочими нодами. Со стороны балансировщиков используется то же подключение, что и для входящего трафика. Рабочие ноды подключены через стек 3750 4-мя 1G линками (по два на каждый 3750). Все физические линки собраны в единый логический также с помощью LACP. Эта сеть используется только для обработки клиентского трафика.

Все соединения внутри кластера Cloudian (Y) идут через третий логический сегмент, построенный поверх 10G. Такая организация помогает избежать проблем на внешнем канале из-за внутреннего трафика и наоборот. Это чрезвычайно нагруженный и важный для работы кластера сегмент. Именно через него осуществляется репликация данных и метаданных, его используют любые процедуры перебалансировки и т.д., поэтому его «непотопляемость» мы выделили в отдельную задачу.

Немного красоты

Вот так выглядит всё в сборе:

3. Сетевое оборудование и балансировщики анфас

4. То же, вид сзади

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

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

5. Рабочие ноды

6. Вид сзади

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

Whitelisting

В комментариях к прошлой статье я обещал подробнее рассказать об устройстве whitelisting.

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

Помните, на первой схеме была ветка на DIST’ы и Cloud? Кроме основного интернет-канала на 20Gb, мы используем агрегированный канал до свитчей, к которым подключаем всех клиентов на уровне ЦОД. Если клиент захочет прямой линк до хранилища, мы сможем настроить VLAN от клиента до наших 4500X c постройкой отдельной трассы (или без неё) и пустить L3. После этого на адреса клиента уже в самом Cloudian настраивается привязка к тарифному плану. Тогда для всех, кто подключен к этому тарифному плану, использование S3 с whitelisting-адресов  считаться не будет.

7. А вот так выглядит специальный интерфейс в Cloudian.

Сейчас у нас такого тарифа в сетке нет, но если вам очень захочется — сможем предоставить.

История постройки

Мы плавно приближаемся к наиболее интересной части истории — строительству хранилища. Будет много фотографий, целых три попытки организовать балансировку трафика и несколько вредных советов. Надеюсь, разбор встретившихся нам на пути неприятностей будет полезен тем, кто готовится работать со скоростями 10Gb+ в вебе.

Экспериментируем с 10G

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

По устоявшейся традиции, прежде чем закупать новое вспомогательное оборудование, мы идем на склад и подбираем более-менее подходящие компоненты. Это позволяет быстро провести тесты и определиться с будущим списком покупок. Разумеется, пока мы не добиваемся надежного на все 100% результата, ничего не уходит на продуктив.

Так было и в этот раз. И если Cisco никаких сюрпризов не подкинули, то с балансировщиками нагрузки «жадность» нас едва не сгубила.

Опыт первый. Серверы Supermicro

Здесь нас подвело желание провести быстрый тест с минимальными затратами. На складе мы обнаружили серверы Supermicro, у которых было прекрасно всё, кроме отсутствия SFP-интерфейсов. Мы решили установить на них наши любимые Intel 520DA2 и тут же столкнулись с первой проблемой: машинки одноюнитовые, а райзеров нет. При этом, нашего корпуса в compatibility-листах почему-то не оказалось, а родных райзеров — очень много.

По совету директора по инновационному развитию Миши Соловьева, мы подключили всё гибкими райзерами для майнинг-ферм. Получился вот такой «кадавр»:

8. Опытный образец №1

Пришлось кое-где применить знаменитую синюю изоленту, чтобы ничего, не дай Бог, не коротнуло. Да, колхоз. Да, стыдно. Но такая «конфигурация» вполне допустима на период эксперимента.

9. Вид сзади

Что из этого получилось, хорошо видно на скриншоте айперфа:

10. На самом деле это не скриншот :)

Показатели очень интересные, верно? Вот и мы взгрустнули. Сначала мы подумали на шпионские чипы, всё разобрали и распрямили.

11. На первый взгляд, шпионских чипов здесь нет

Вспомнили курс физики: электромагнитные наводки, высокочастотные сигналы и т.д… Разумеется, продолжать эксперимент с таким количеством и качеством «колхоза» не имело смысла. Так что мы окончательно разобрали систему и вернули серверы на место.

Опыт второй. Citrix Netscaler MPX8005

В процессе возвращения серверов на место мы нашли новых героев: Citrix Netscaler MPX8005. Это замечательное брендовое железо, к тому же, практически не использованное. Выглядят они вот так:

12. Салазки в стойку не поместились по длине, но мы дальновидно решили отложить это на потом

Разместили оборудование в стойке, скоммутировали и настроили. Это действительно отличные «взрослые» железки, по 2 SFP-слота под 10GB на каждый, HA, продвинутые алгоритмы, есть даже L7. Правда, до 5 гигабит по лицензии, но мы всё равно использовали L3, а там этих лимитов нет.

Скрестили пальцы, тестируем. Скорости нет. На интерфейсах — сплошные ошибки о неподходящих трансиверах, скорость примерно 5 гигабит, постоянные дропы. Вспомнили гибкие райзеры, взгрустнули снова. Даже там скорость была повыше, а ошибок поменьше. Начинаем разбираться:

show channel LA/1
 
1)  Interface LA/1 (802.3ad Link Aggregate) #10
  flags=0x4100c020 <ENABLED, UP, AGGREGATE, UP, HAMON, HEARTBEAT, 802.1q>
  MTU=9000, native vlan=1, MAC=XXX, uptime 0h03m23s
  Requested: media NONE, speed AUTO, duplex NONE, fctl NONE,
        	throughput 160000
  Link Redundancy Throughput 80000
  Actual: throughput 20000
  LLDP Mode: NONE
  RX: Pkts(9388) Bytes(557582) Errs(0) Drops(1225) Stalls(0)
  TX: Pkts(10514) Bytes(574232) Errs(0) Drops(0) Stalls(0)
  NIC: InDisc(0) OutDisc(0) Fctls(0) Stalls(0) Hangs(0) Muted(0)
  bandwidthHigh: 160000 Mbits/sec, bandwidthNormal: 160000 Mbits/sec.
  LA mode: AUTO
 
> show interface 10/1
 
1)  Interface 10/1 (10G Ethernet, unsupported fiber SFP+, 10 Gbit) #1
  flags=0x400c020 <ENABLED, UP, BOUND to LA/1, UP, autoneg, 802.1q>
  LACP <Active, Long timeout, key 1, priority 32768>
  MTU=9000, MAC=XXX, uptime 0h05m44s
  Requested: media AUTO, speed AUTO, duplex AUTO, fctl OFF,
        	throughput 0
  Actual: media FIBER, speed 10000, duplex FULL, fctl OFF, throughput 10000
  LLDP Mode: TRANSCEIVER,    	LR Priority: 1024
 
  RX: Pkts(8921) Bytes(517626) Errs(0) Drops(585) Stalls(0)
  TX: Pkts(9884) Bytes(545408) Errs(0) Drops(3) Stalls(0)
  NIC: InDisc(0) OutDisc(0) Fctls(0) Stalls(0) Hangs(0) Muted(0)
  Bandwidth thresholds are not set.
 
> show interface 10/2
 
1)  Interface 10/2 (10G Ethernet, unsupported fiber SFP+, 10 Gbit) #0
  flags=0x400c020 <ENABLED, UP, BOUND to LA/1, UP, autoneg, 802.1q>
  LACP <Active, Long timeout, key 1, priority 32768>
  MTU=9000, MAC=XXX, uptime 0h05m58s
  Requested: media AUTO, speed AUTO, duplex AUTO, fctl OFF,
        	throughput 0
  Actual: media FIBER, speed 10000, duplex FULL, fctl OFF, throughput 10000
  LLDP Mode: TRANSCEIVER,    	LR Priority: 1024
 
  RX: Pkts(8944) Bytes(530975) Errs(0) Drops(911) Stalls(0)
  TX: Pkts(10819) Bytes(785347) Errs(0) Drops(3) Stalls(0)
  NIC: InDisc(0) OutDisc(0) Fctls(0) Stalls(0) Hangs(0) Muted(0)
  Bandwidth thresholds are not set.

Мы использовали родные трансиверы Cisco, с которыми, по идее, никаких проблем возникнуть не должно. Даже оптику проверили и на всякий случай поменяли трансиверы — та же самая картина. Не едет наша машина, и всё тут! Смотрим внимательнее.

«Красивые» трансиверы Cisco:

ix1: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.7.4> port 0xe000-0xe01f mem 0xf7800000-0xf781ffff,0xf7840000-0xf7843fff irq 17 at device 0.1 on pci1
ix1: ixgbe bus speed = 5.0Gbps and PCIe lane width = 8
SFP+/SFP, vendor CISCO-AVAGO , part number XXX , 10G 0x10 1G 0x00 CT 0x00
  *** Unsupported SFP+/SFP type!

Не определяются нормально трансиверы, unsupported же!

Пришлось найти самые-самые «родные»:

13. Самые родные трансиверы на диком западе

ix0: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.7.4> port 0xe020-0xe03f mem 0xf7820000-0xf783ffff,0xf7844000-0xf7847fff irq 16 at device 0.0 on pci1
platform: Manufacturer Citrix Inc.
platform: NSMPX-8000-10G 4*CPU+6*E1K+2*IX+1*E1K+4*CVM 1620 675320 (28), manufactured at 8/10/2015
platform: serial 4NP602H7H0
platform: sysid 675320 - NSMPX-8000-10G 4*CPU+6*E1K+2*IX+1*E1K+4*CVM 1620
ix0: ixgbe bus speed = 5.0Gbps and PCIe lane width = 8
SFP+/SFP, vendor CITRIX           	, part number XXX   , 10G 0x10 1G 0x01 CT 0x00
ix0: [ITHREAD]
10/2: Ethernet address: 00:e0:ed:45:39:f8
ix1: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.7.4> port 0xe000-0xe01f mem 0xf7800000-0xf781ffff,0xf7840000-0xf7843fff irq 17 at device 0.1 on pci1
ix1: ixgbe bus speed = 5.0Gbps and PCIe lane width = 8
SFP+/SFP, vendor CITRIX           	, part number XXX  , 10G 0x10 1G 0x01 CT 0x00

Эти трансиверы без проблем определились, но ситуацию это не спасло. Обновили прошивки — то же самое. Поддержка Citrix решила тактично отмолчаться (нет, не из-за родословной трансиверов).

Мы глубоко вздохнули и зарылись в аппаратные спецификации. Выяснилось, что ответ всё это время был у нас перед глазами: ixgbe bus speed = 5.0Gbps and PCIe lane width = 8. Это проблема с картой. Ей самой не хватает скорости PCIe. У наших Citrix максимальная производительность самого PCI-e слота под карту с трансиверами составляет 5.0Gbps, о чем он нам и кричал все это время. Как Citrix на MPX8015 (аппаратно он точно такой же!) 15 гигабит выдавать хотели, не понятно. Зато мы поняли, почему такие «классные» балансировщики всё это время лежали на складе. Работать корректно с 10G линками они не могут в принципе.

Опыт последний. Используем правильное железо и делаем красиво

Здесь наше терпение закончилось вместе с верой в человечество, и пришлось применять технологию «отжайл», чтобы добыть нормальное железо в виде HP ProLiant DL360 G9 с фотографий выше. Они сюрпризов нам устраивать не стали, качают 10G и не жалуются. :)

Нагрузочное тестирование

Поскольку мы не приемлем подход «hujak-hujak — и в продакшен», да и знаем по опыту, что не протестированная система после сборки почти со 100% гарантией окажется неработоспособной, мы решили провести нагрузочное тестирование. К тому же, с его помощью можно сделать некоторый тюнинг на будущее.

Для генерации нагрузки был выбран привычный инструмент — Apache Jmetr. Он сам по себе весьма неплох, как я уже писал пару статей назад, и это одно из наиболее гибких решений на рынке, даже несмотря на то, как Java любит кушать. Для работы с S3 мы использовали самописный модуль с использованием AWS SDK, также на Java. В тестах нам удалось добиться скорости в 12,5 Гбит на запись для файлов более 250 мегабайт при параллельной загрузке чанками в 5 мегабайт, и для файлов менее 5 мегабайт — обработки примерно 3000 HTTP запросов в секунду. При параллельном запуске обоих тестов получилось около 11 Гигабит и 2200 запросов в секунду. При этом есть возможность улучшения работы при смешанной нагрузке и с мелкими объектами. Мы «уткнулись» в CPU, а второй сокет у нас свободен. На генераторе нагрузки тестовые файлы брались из оперативной памяти, чтобы исключить влияние на результаты дисковой подсистемы самого генератора. Для проведения тестов, помня о любви Java к оперативной памяти и необходимости работы с большим количеством потоков при параллельной загрузке, в качестве генератора мы использовали сервер HP DL980 g7. Это восьмиюнитовый сервер с 8 процессорами Intel E7- 4870 и 512Gb оперативной памяти на борту.

Внутри команды к нему прилепилась ласковая кличка Бегемотик.

14. Наш бегемотик. Правда, чем-то похож?

15. Вид сзади. Страшные кабели внизу в центре — это кроссконнект внутренней межмостовой шины

16. Так выглядит одна из двух голов сервера. В каждой установлено по 4 процессора и 16 планок по 16 гигабайт оперативной памяти

17. Чтобы комфортно использовать Htop в консоли такого сервера, нужен большой монитор :)

На практике смешанный тест заметно нагрузил даже такой мощный сервер.
Чтобы прийти к полученным результатам производительности, нам пришлось перевести внутреннюю сеть кластера на 9k jumbo frame’ы и слегка тюнинговать сетевой стек балансировщиков и рабочих нод (мы используем CentOS Linux), а также оптимизировать ряд других параметров ядра на рабочих нодах:  

cat /etc/sysctl.conf
…
 
kernel.printk = 3 4 1 7
read_ahead_kb = 1024
write_expire = 250
read_expire = 250
fifo_batch = 128
front_merges = 0
net.core.wmem_default = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 16777216
net.core.rmem_max = 16777216
net.core.somaxconn = 5120
net.core.netdev_max_backlog = 50000
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_max_syn_backlog = 30000
net.ipv4.tcp_max_tw_buckets = 2000000
fs.file-max = 196608
vm.overcommit_memory = 1
vm.overcommit_ratio = 100
vm.max_map_count = 65536
vm.dirty_ratio = 40
vm.dirty_background_ratio = 5
vm.dirty_expire_centisecs = 100
vm.dirty_writeback_centisecs = 100
net.ipv4.tcp_fin_timeout=10
net.ipv4.tcp_congestion_control=htcp
net.ipv4.netfilter.ip_conntrack_max=1048576
net.core.rmem_default=65536
net.core.wmem_default=65536
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.ip_local_port_range=1024 65535

Основные настройки, подвергшиеся тюнингу, — это размеры буферов, количество сетевых соединений, количество подключений к порту и соединений, отслеживаемых фаерволами, а также таймауты.

Cisco C3750 + LACP = pain
Еще один подводный камень в сетевой производительности — балансировка нагрузки при использовании LACP/LAGp. К сожалению, Cisco 3750 не умеют балансировать нагрузку по портам, только по адресам источника и назначения. Чтобы добиться корректной балансировки трафика, пришлось навесить по 12 IP адресов на bond-интерфейсы рабочих нод, «смотрящих» в сторону клиентов. Условно, по 3 на каждый физический линк. При такой конфигурации можно было обойтись вообще без LACP на «внешних» интерфейсах рабочих нод, так как все адреса указаны в конфиге Nginx, но тогда при потере линка мы бы автоматически снижали вес ноды в балансировке. При «отвале» линка LACP позволяет сохранить полную доступность по всем адресам.

bond0.10  Link encap:Ethernet  HWaddr XXX
        	inet addr:192.168.XX Bcast:192.168.XX  Mask:255.255.255.0
        	UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
        	RX packets:2390824140 errors:0 dropped:0 overruns:0 frame:0
        	TX packets:947068357 errors:0 dropped:0 overruns:0 carrier:0
        	collisions:0 txqueuelen:0
        	RX bytes:18794424755066 (17.0 TiB)  TX bytes:246433289523 (229.5 GiB)
 
bond0.10:0 Link encap:Ethernet  HWaddr XXX
        	inet addr:192.168.XX  Bcast:192.168.XX Mask:255.255.255.0
        	UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
 
bond0.10:1 Link encap:Ethernet  HWaddr XXX
        	inet addr:192.168.XX Bcast:192.168.XX  Mask:255.255.255.0
        	UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
 
bond0.10:2 Link encap:Ethernet  HWaddr XXX
        	inet addr:192.168.XX Bcast:192.168.XX  Mask:255.255.255.0
        	UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
 
bond0.10:3 Link encap:Ethernet  HWaddr XXX
        	inet addr:192.168.XX  Bcast:192.168.XX  Mask:255.255.255.0
        	UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
 
bond0.10:4 Link encap:Ethernet  HWaddr XXX
        	inet addr:192.168.XX Bcast:192.168.XX  Mask:255.255.255.0
        	UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
 
bond0.10:5 Link encap:Ethernet  HWaddr XXX
        	inet addr:192.168.XX  Bcast:192.168.XX  Mask:255.255.255.0
        	UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
 
bond0.10:6 Link encap:Ethernet  HWaddr XXX
        	inet addr:192.168.XX  Bcast:192.168.XX  Mask:255.255.255.0
        	UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
 
bond0.10:7 Link encap:Ethernet  HWaddr XXX
        	inet addr:192.168.XX  Bcast:192.168.XX  Mask:255.255.255.0
        	UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
 
bond0.10:8 Link encap:Ethernet  HWaddr XXX
        	inet addr:192.168.XX  Bcast:192.168.XX  Mask:255.255.255.0
        	UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
 
bond0.10:9 Link encap:Ethernet  HWaddr XXX
        	inet addr:192.168.XX Bcast:192.168.XXMask:255.255.255.0
        	UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
 
bond0.10:10 Link encap:Ethernet  HWaddr XXX
        	inet addr:192.168.XX  Bcast:192.168.XX  Mask:255.255.255.0
        	UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1

Функциональное тестирование

Уже закончив работу над хранилищем, мы познакомились с сервисом flexify.io. Они помогают облегчить миграцию между различными объектными хранилищами. Но чтобы стать партнером Flexify, необходимо пройти серьезные тесты. «А почему бы и нет?» — подумали мы. Стороннее тестирование — это всегда полезный опыт.

Основная задача тестов — проверка работы методов протокола S3 через их прокси по отношению к различным конфигурациям, среди которых может быть любой набор S3-compatible бакетов, поддерживаемых сервис-провайдером.

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

В негативных тестах пытались передать невалидные данные везде, где это только возможно. Особое внимание уделялось сохранности данных в процессе работы.

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

О широте покрытия можно судить по тестам, которые использовались как через прокси, так и напрямую. Большинство тестов, особенно те, что работают с объектами, параметризованы и проверяют большое количество различных объектов, диапазонов и т.д.

 
Как нетрудно догадаться, это достаточно жесткое тестирование, но мы прошли его в целом позитивно. Некоторые проблемы возникли из-за отсутствия у нас в тот момент поддержки SSE и небольших косяков с поддержкой Unicode:

Провалился аплоад с ключами, содержащими:

• U+0000-U+001F – первые 32 нечитаемых контрольных символа. На Amazon, к примеру, напрямую не заливается только первый U+0000.

• А также U+18D7C, U+18DA8, U+18DB4, U+18DBA, U+18DC4, U+18DCE. Это тоже нечитаемые символы, но Amazon их принимает в качестве ключей. Со всеми остальными символами проблем не возникло.

При чтении содержимого бакета возникает проблема на 66,675 ключе, который содержит символ U+FFFE. Получить полный список ключей в бакете, содержащем объект с таким ключом, не получается.

В остальном тесты прошли успешно, и в конце сентября мы появились в списке доступных поставщиков!

Небольшое послесловие и бонус для читателей

Ранее я писал, что Cloudian HyperStore, не смотря на свои многочисленные преимущества, практически не освещен в русскоговорящем сегменте интернета.

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

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

Те из вас, кому захотелось пощупать ручками то, о чем мы говорим уже 2 статьи подряд, могут воспользоваться формой обратной связи на этой страничке и лично выяснить, в чем соль. Стандартно мы даем 15Gb на 2 недели бесплатно, естественно, с пользовательским доступом. Если у вас возникнет желание поделиться впечатлениями от работы с хранилищем, пишите мне в личку. :)

А для тех, кому 15 Gb на 2 недели мало, у нас есть небольшой квест! На фотографиях в статье мы разместили трёх бегемотиков. Первые 50 человек, которые их найдут, получат 30Gb на 4 недели. Чтобы получить увеличенный тест, напишите в комментариях номера картинок, где спрятались бегемотики, и подайте заявку по ссылке выше. Не забудьте в заявке указать ссылку на свой комментарий.

По традиции, если у вас остались вопросы, задавайте их в комментариях.
Я с удовольствием на них отвечу.

Автор: Алексей

Источник