Cómo creamos el almacenamiento S3 DataLine. Experimentos, pruebas y un poco sobre hipopótamos

Hola de nuevo, Alexey Pristavko está en contacto, y esta es la segunda parte de mi historia sobre la línea de datos de almacenamiento de objetos S3 basada en Cloudian HyperStore.

Hoy hablaré en detalle sobre cómo está organizado nuestro almacenamiento S3 y qué dificultades encontramos en el proceso de creación. Asegúrese de tocar el tema "hierro" y analizar el equipo en el que terminamos quedándonos.

Vamos!

Si durante la lectura desea familiarizarse con la arquitectura de la aplicación de la solución Cloudian, encontrará su análisis detallado en el artículo anterior . Allí discutimos en detalle el dispositivo interno de Cloudian, la tolerancia a fallas y la lógica del SDS incorporado.

El esquema final del equipo físico.

Como más adelante hablaremos de nuestro "tormento de elección", daré inmediatamente la lista final de hierro a la que hemos llegado. Pequeño descargo de responsabilidad: la elección del equipo de red se debió en gran medida a su presencia en nuestro (por cierto, muy sólido) almacén.

Entonces, a nivel físico del almacenamiento, tenemos el siguiente equipo:

Nombre	Función	Configuracion	Cantidad
Servidor Lenovo System x3650 M5	Nodo de trabajo	1x Xeon E5-2630v4 2.2GHz, 4x 16GB DDR4, 14x 10TB 7.2K 6Gbps SATA 3.5 ", 2x SSD de 480 GB, Intel x520 Dual Port 10GbE SFP +, Fuente de alimentación HS 2x750W	4 4
Servidor HP ProLiant DL360 G9	Nodo equilibrador de carga	2 E5-2620 v3, 128G de RAM, 2 SSD de 600 GB, 4 discos duros SAS, Intel x520 Dual Port 10GbE SFP +	2
Conmutador Cisco C4500	Puerta de enlace fronterizo	Catalyst WS-C4500X-16SFP +	2
Conmutador Cisco C3750	Extensor de puerto	Catalizador WS-C3750X-24T con C3KX-NM-10G	2
Conmutador Cisco C2960	plano de control	Catalizador WS-C2960 + 48PST-L	1

Para una mejor comprensión de la arquitectura, analizaremos todos los elementos y hablaremos sobre sus características y tareas.

Comencemos con los servidores. Los servidores de Lenovo tienen una configuración especial que se implementa de manera conjunta y en total conformidad con las recomendaciones y especificaciones de Cloudian. Por ejemplo, usan un controlador con acceso directo al disco. Como en nuestro caso RAID está organizado a nivel de software de aplicación, este modo aumenta la confiabilidad y acelera el subsistema de disco. Se pueden comprar exactamente los mismos servidores como un dispositivo Cloudian junto con todas las licencias.

Los servidores de equilibrio de carga con Nginx para CentOS garantizan una distribución uniforme de la carga en los nodos de trabajo y abstraen al usuario de la organización del tráfico interno. Y como un bono agradable, si es necesario, puede organizar un caché en ellos.

El par Cisco 4500X dieciséis 10GB SFP + sirve como núcleo y borde de nuestra pequeña pero orgullosa red de almacenamiento. Por supuesto, el hierro está un poco pasado de moda, pero no es inferior al "nuevo" en confiabilidad, tiene redundancia interna y su funcionalidad cumple con todos nuestros requisitos. C3750 desempeña el papel de extensor de fábrica, no hay necesidad de meter transceptores 1G en ranuras 10G. Y cambiar completamente a enlaces de 10 GB tampoco tiene mucho sentido todavía. Como han demostrado las pruebas, nos encontramos con el procesador y los discos antes.

El siguiente diagrama ilustra con suficiente detalle la organización física descrita por mí:

1. Esquema de la organización de almacenamiento físico.

Veamos el esquema. Como puede ver, la tolerancia a fallas a nivel físico se realiza duplicando y conectando cada uno de los dispositivos con al menos dos enlaces ópticos, uno para cada dispositivo en un par. Esto nos da la garantía de mantener la conectividad física en el circuito durante un accidente de cualquier dispositivo de red o dos dispositivos de diferentes pares al mismo tiempo.

Vamos debajo del esquema. Ambos pares de Cisco (4500/4500, 3750/3750) se combinan en un solo dispositivo lógico utilizando la pila y VSS. La pila se ensambla con dos cables de pila, VSS a través de tres enlaces ópticos de 10G. Esto le permite asegurarse de que ambos dispositivos en cada par interactúen como un todo. Tal agrupación nos permite trabajar dentro del marco de un segmento L2 transparente a través de ambos dispositivos de un par y hacer una agregación general de enlaces usando LACP, ya que esta tecnología es soportada de forma nativa tanto por el sistema operativo del servidor como por Cisco IOS. Desde el lado del servidor, parece que funciona con un conmutador en lugar de dos, y encima de la aplicación hay un canal agregado de doble capacidad.

Todos los equipos de red cambian entre sí y a los canales entrantes se realizan mediante enlaces ópticos de 10G, el equipo del servidor se conecta mediante cables Cisco 10G Twinax y 1G de cobre.

BGP se usa para la tolerancia a fallas en el canal entrante, y Round Robin DNS se usa para equilibrar las direcciones IP externas. Las direcciones externas en sí están estacionadas en servidores de equilibrio de carga y, si es necesario, migran entre nodos utilizando el paquete Pacemaker / Corosync.

El monitoreo y control a través de IPMI se realiza a través de un enlace interno directo. Todas las interfaces de administración (tanto servidores como Cisco) están conectadas a través de conmutadores de plano de control separados. Ellos, a su vez, están incluidos en la red de control del centro de datos. Esto nos garantiza la imposibilidad de perder la comunicación con el equipo durante el trabajo o como resultado de un accidente en una red externa. Para el caso más extremo, hay asistentes con KVM.

Red lógica

Para comprender cómo funciona la red lógica S3 del almacenamiento DataLine, pasemos a otro esquema:


2. Diagrama de red lógica de almacenamiento

Como puede ver, la lógica de red consta de varios segmentos.

Una red externa (Q) con una capacidad total de 20G está conectada directamente a Provider Edge. Esto es seguido por el Cisco 4500 y los balanceadores.

El siguiente bloque lógico (X) es la VLAN entre los equilibradores y los nodos de trabajo. Los equilibradores usan la misma conexión que para el tráfico entrante. Los nodos de trabajo están conectados a través de la pila 3750 con 4 enlaces 1G (dos por cada 3750). Todos los enlaces físicos se ensamblan en uno solo lógico usando LACP también. Esta red se usa solo para procesar el tráfico del cliente.

Todas las conexiones dentro del clúster Cloudian (Y) pasan por un tercer segmento lógico construido sobre 10G. Dicha organización ayuda a evitar problemas en el canal externo debido al tráfico interno y viceversa. Este es un segmento extremadamente cargado e importante para el funcionamiento del clúster. Es a través de él que los datos y metadatos se replican, se utilizan en cualquier procedimiento de reequilibrio, etc., por lo tanto, distinguimos su "insumergibilidad" como una tarea separada.

Un poco de belleza

Así es como se ve todo:


3. Equipos de red y equilibradores integrales


4. Lo mismo, vista trasera

Presta atención al cambio. En artículos anteriores, mis colegas escribieron sobre la importancia de los cables de marcado de color, pero no estará fuera de lugar tocar este tema aquí.

Utilizamos el cambio de color no solo para la red, sino también para la alimentación. Esto permite a nuestros ingenieros navegar rápidamente en el rack y reduce la influencia del factor humano durante la conmutación.


5. Nodos de trabajo


6. Vista trasera

En esta foto, puede ver claramente qué tan apretados están los servidores de trabajo llenos de discos: prácticamente no hay ranuras vacías incluso en la parte posterior. Por cierto, dicha organización de cables en paquetes compactos realiza no solo una función estética, sino que también evita la superposición de los ventiladores de las fuentes de alimentación, evitando que el hierro se sobrecaliente.

Lista blanca

En los comentarios sobre el último artículo, prometí hablar más sobre el dispositivo de la lista blanca.

Si por algún motivo acordamos con el cliente excluir de las cuentas todo el trabajo con el almacenamiento desde el interior del centro de datos o por canales directos a su equipo, entonces debemos organizar una conexión privada al almacenamiento.

¿Recuerdas que en el primer diagrama había una rama en DIST y Cloud? Además del canal principal de Internet de 20 Gb, utilizamos un canal agregado para los conmutadores, al que conectamos a todos los clientes en el nivel del centro de datos. Si el cliente quiere un enlace directo al almacenamiento, podemos configurar la VLAN desde el cliente a nuestro 4500X con la construcción de una ruta separada (o sin ella) e iniciar L3. Después de eso, el enlace al plan de tarifas se configura en las direcciones del cliente que ya están en Cloudian. Entonces, para todos los que estén conectados a este plan de tarifas, no se considerará el uso de S3 de las direcciones de la lista blanca.


7. Y aquí hay una interfaz especial en Cloudian.

Ahora no tenemos esa tarifa en la red, pero si realmente lo desea, podemos proporcionarla.

Historia de la construccion

Poco a poco nos acercamos a la parte más interesante de la historia: la construcción de una instalación de almacenamiento. Habrá muchas fotos, hasta tres intentos de organizar el equilibrio del tráfico y algunos malos consejos. Espero que el análisis de los problemas que encontramos en el camino sea útil para aquellos que se están preparando para trabajar con velocidades de 10 Gb + en la web.

Experimentando con 10G

Antes de ir directamente a la esencia de esta sección, me permito hacer otro pequeño descargo de responsabilidad.

Según una tradición establecida, antes de comprar nuevos equipos auxiliares, vamos al almacén y seleccionamos componentes más o menos adecuados. Esto le permite realizar pruebas rápidamente y decidir sobre una futura lista de compras. Por supuesto, aunque no estamos logrando un resultado 100% confiable, no se gasta nada en lo productivo.

Así fue esta vez. Y si Cisco no arrojó ninguna sorpresa, entonces con la "avaricia" de los equilibradores de carga casi nos arruina.

La primera experiencia Servidores Supermicro

Aquí nos decepcionó el deseo de realizar una prueba rápida con un costo mínimo. En el almacén, encontramos servidores Supermicro que tenían todo bien, excepto la falta de interfaces SFP. Decidimos instalar nuestro querido Intel 520DA2 en ellos e inmediatamente enfrentamos el primer problema: las máquinas son de una sola unidad, pero no hay elevadores. Al mismo tiempo, por alguna razón, nuestro cuerpo no estaba en listas de compatibilidad, pero había muchos nativos.

Siguiendo el consejo de la directora de desarrollo innovador, Misha Solovyov, conectamos todo con elevadores flexibles para granjas mineras. El resultado fue tal "cadáver":


8. Prototipo No. 1

Tuve que usar la famosa cinta eléctrica azul en algunos lugares, para que, Dios no lo quiera, haga algo corto. Sí, la granja colectiva. Sí, avergonzado Pero tal "configuración" es bastante aceptable para el período del experimento.


9. Vista posterior

Lo que resultó de esto es claramente visible en la captura de pantalla del iperf:


10. En realidad esta no es una captura de pantalla :)

Las métricas son muy interesantes, ¿verdad? Entonces estábamos tristes. Al principio pensamos en chips espías, desarmamos y enderezamos todo.


11. A primera vista, no hay chips espías aquí

Recordaron el curso de la física: interferencia electromagnética, señales de alta frecuencia, etc. ... Por supuesto, continuar el experimento con tal cantidad y calidad de la "granja colectiva" no tenía sentido. Así que finalmente desarmamos el sistema y volvimos a colocar los servidores en su lugar.

La segunda experiencia. Citrix Netscaler MPX8005

En el proceso de devolver los servidores al lugar, encontramos nuevos héroes: Citrix Netscaler MPX8005. Este es un hierro de marca maravilloso, además, casi nunca se usa. Se ven así:


12. El portaobjetos en el estante no encajaba en longitud, pero decidimos posponerlo hasta más tarde.

Equipo colocado en un rack, conmutado y configurado. Estas son piezas de hierro realmente "excelentes" para adultos, 2 ranuras SFP para 10GB cada una, HA, algoritmos avanzados, incluso hay L7. Es cierto, hasta 5 gigabits bajo licencia, pero aún utilizamos L3, pero no existen tales límites.

Dedos cruzados, prueba. No hay velocidad En las interfaces: errores sólidos sobre transceptores inadecuados, velocidad de aproximadamente 5 gigabits, caídas constantes. Recordaron los risers flexibles, volvieron a estar tristes. Incluso allí, la velocidad era más alta y menos errores. Comenzamos a entender:

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. 

Utilizamos transceptores Cisco nativos, con los cuales, en teoría, no deberían surgir problemas. Incluso revisaron la óptica y, por si acaso, cambiaron los transceptores, la misma imagen. Nuestro coche no funciona, ¡y eso es todo! Lo miramos más de cerca.

Transceptores Cisco "hermosos":

 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! 

¡Los transceptores no se detectan normalmente, sin soporte!

Tenía que encontrar la mayoría de los "parientes":


13. Los transceptores más nativos del salvaje oeste

 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 

Estos transceptores se determinaron sin ningún problema, pero esto no salvó la situación. Firmware actualizado: lo mismo. El soporte de Citrix decidió guardar silencio con tacto (no, no por el pedigrí del transceptor).

Respiramos profundamente y nos enterramos en las especificaciones de hardware. Resultó que la respuesta todo este tiempo estuvo ante nuestros ojos: velocidad del bus ixgbe = 5.0Gbps y ancho de carril PCIe = 8. Este es un problema con la tarjeta. Ella misma carece de velocidad PCIe. Nuestro Citrix tiene el máximo rendimiento de la ranura PCI-e para una tarjeta con transceptores de 5.0 Gbps, que nos gritó todo este tiempo. Al igual que Citrix en MPX8015 (¡es exactamente lo mismo en hardware!) Querían entregar 15 gigabits, no está claro. Pero entendimos por qué esos equilibradores "geniales" todo este tiempo yacían en un almacén. No pueden funcionar correctamente con enlaces 10G en principio.

La ultima experiencia. Usamos el hierro correcto y lo hacemos hermoso

Aquí, nuestra paciencia terminó con nuestra fe en la humanidad, y tuvimos que usar la tecnología "de repuesto" para obtener el hardware normal en forma de HP ProLiant DL360 G9 de las fotos de arriba. No comenzaron a organizar sorpresas para nosotros, descargan 10G y no se quejan. :)

Prueba de carga

Como no aceptamos el enfoque de hujak-hujak-y-producción, y sabemos por experiencia que un sistema no probado después del ensamblaje con una garantía de casi el 100% será inoperable, decidimos realizar pruebas de carga. Además, con su ayuda, puede hacer algunos ajustes para el futuro.

Para generar la carga, se eligió la herramienta habitual: Apache Jmetr. Solo es bastante bueno, ya que escribí un par de artículos, y esta es una de las soluciones más flexibles del mercado, a pesar de que a Java le encanta comer. Para trabajar con S3, utilizamos un módulo autoescrito con AWS SDK, también en Java. En las pruebas, pudimos alcanzar una velocidad de 12.5 Gbps para la escritura de archivos de más de 250 megabytes con carga paralela por fragmentos de 5 megabytes, y para archivos de menos de 5 megabytes, procesando alrededor de 3000 solicitudes HTTP por segundo. Al ejecutar ambas pruebas en paralelo, resultó aproximadamente 11 Gigabits y 2200 solicitudes por segundo. Al mismo tiempo, existe la posibilidad de mejorar el trabajo con una carga mixta y con objetos pequeños. Nos "enterramos" en la CPU, y el segundo zócalo está libre. En el generador de carga, se tomaron archivos de prueba de la RAM para excluir la influencia en los resultados del subsistema de disco del generador mismo. Para las pruebas, recordando el amor de Java por la RAM y la necesidad de trabajar con una gran cantidad de subprocesos durante la carga paralela, utilizamos el servidor HP DL980 g7 como generador. Este es un servidor de ocho unidades con 8 procesadores Intel E7-4870 y 512 Gb de RAM a bordo.

Dentro del equipo, el apodo cariñoso Behemoth se le pegó.


14. Nuestro hipopótamo. Es cierto, algo similar?


15. Vista trasera. Los cables de miedo en el centro inferior son una conexión cruzada del bus de puente interno


16. Este es uno de los dos objetivos del servidor. Cada uno tiene 4 procesadores y 16 ranuras de 16 gigabytes de RAM


17. Para usar Htop cómodamente en la consola de dicho servidor, necesitas un monitor grande :)

En la práctica, una prueba mixta ha cargado notablemente incluso un servidor tan poderoso.
Para llegar a los resultados de rendimiento obtenidos, tuvimos que transferir la red interna del clúster a marcos jumbo de 9k y ajustar ligeramente la pila de red de equilibradores y nodos de trabajo (usamos CentOS Linux), así como optimizar una serie de otros parámetros del núcleo en los nodos de trabajo:

 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 

Las configuraciones principales que se sometieron a ajustes son el tamaño de los búferes, el número de conexiones de red, el número de conexiones al puerto y las conexiones monitoreadas por firewalls, así como los tiempos de espera.

Cisco C3750 + LACP = dolor
Otro escollo en el rendimiento de la red es el equilibrio de carga cuando se usa LACP / LAGp. Desafortunadamente, el Cisco 3750s no puede equilibrar la carga a través de los puertos, solo en las direcciones de origen y destino. Para lograr el equilibrio de tráfico correcto, tuve que colgar 12 direcciones IP en las interfaces de enlace de los nodos de trabajo, "mirando" hacia los clientes. Condicionalmente, 3 por cada enlace físico. Con esta configuración, fue posible prescindir de LACP en las interfaces "externas" de los nodos de trabajo, ya que todas las direcciones se especifican en la configuración de Nginx, pero si el enlace se perdiera, reduciríamos automáticamente el peso del nodo en el equilibrio. Con el "volcado", el enlace LACP le permite mantener la accesibilidad total a todas las direcciones.

 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 

Prueba funcional

Después de terminar el trabajo en el repositorio, nos reunimos con el servicio flexify.io. Ayudan a facilitar la migración entre diferentes almacenes de objetos. Pero para convertirse en un socio de Flexify, debe pasar pruebas serias. "¿Por qué no?" - pensamos Las pruebas de terceros siempre son una experiencia gratificante.

La tarea principal de las pruebas es verificar el funcionamiento de los métodos del protocolo S3 a través de sus servidores proxy en relación con varias configuraciones, entre las cuales puede haber cualquier conjunto de cubos compatibles con S3 admitidos por el proveedor de servicios.

En primer lugar, se verifican los métodos que funcionan con objetos en el depósito. Nuestro almacenamiento se probó utilizando una amplia gama de datos de prueba, el comportamiento de los métodos se probó para objetos de varios tamaños y contenidos, para claves que contienen todo tipo de combinaciones de caracteres Unicode.

En pruebas negativas, intentaron transferir datos no válidos siempre que fue posible. Se prestó especial atención a la seguridad de los datos en el proceso.

Los métodos que trabajan con cubos también se han probado, pero principalmente en escenarios positivos. El objetivo de estas pruebas fue verificar que el uso de métodos a través de un proxy no conlleve ningún problema grave, por ejemplo, corrupción de datos o fallas.

La amplitud de la cobertura se puede juzgar por las pruebas que se utilizaron tanto a través de proxies como directamente. La mayoría de las pruebas, especialmente aquellas que trabajan con objetos, están parametrizadas y prueban una gran cantidad de diferentes objetos, rangos, etc.





Como puede suponer, esta es una prueba bastante difícil, pero generalmente la pasamos positivamente. Surgieron algunos problemas debido a la falta de soporte para SSE y pequeñas escuelas con soporte Unicode en ese momento:

Error al cargar con claves que contienen:

• U + 0000-U + 001F: los primeros 32 caracteres de control ilegibles. En Amazon, por ejemplo, solo el primer U + 0000 no se vierte directamente.
  

• Y también U + 18D7C, U + 18DA8, U + 18DB4, U + 18DBA, U + 18DC4, U + 18DCE. Estos también son caracteres ilegibles, pero Amazon los acepta como claves. No hubo problemas con todos los demás personajes.
  

Al leer el contenido del depósito, hay un problema en la tecla 66,675, que contiene el símbolo U + FFFE. No es posible obtener una lista completa de claves en un depósito que contiene un objeto con dicha clave.

De lo contrario, las pruebas fueron exitosas, y a fines de septiembre aparecimos en la lista de proveedores disponibles.

Un breve epílogo y bonificación para los lectores.

Anteriormente, escribí que Cloudian HyperStore, a pesar de sus muchas ventajas, prácticamente no está cubierto en el segmento de Internet de habla rusa.

El primer artículo fue sobre los conceptos básicos de trabajar con Cloudian. Desmontamos su estructura interna, matices arquitectónicos y leemos la traducción de la documentación oficial.

Hoy les conté cómo construimos nuestro propio almacenamiento y qué matices y dificultades encontramos.

Aquellos de ustedes que quieran sentir con bolígrafos de lo que estamos hablando 2 artículos seguidos pueden usar el formulario de comentarios en esta página y descubrir personalmente qué es la sal. Como estándar, le damos 15Gb durante 2 semanas gratis, por supuesto, con acceso de usuario. Si desea compartir sus impresiones de trabajar con el repositorio, escríbame en PM. :)

Y para aquellos que no son suficientes 15 Gb durante 2 semanas, ¡tenemos una pequeña búsqueda! En las fotografías del artículo, colocamos tres hipopótamos. Las primeras 50 personas que las encuentren recibirán 30 Gb durante 4 semanas. Para obtener una prueba ampliada, escriba en los comentarios los números de las imágenes donde se escondieron los hipopótamos y solicite el enlace de arriba. No olvide incluir un enlace a su comentario en la aplicación.

Por tradición, si tiene alguna pregunta, hágala en los comentarios.
Estaré encantado de responderlas.