{"id":91090,"date":"2020-08-08T13:42:11","date_gmt":"2020-08-08T11:42:11","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/arhitektura-s3-3-goda-evolyuczii-mail-ru-cloud-storage"},"modified":"2020-08-08T13:42:11","modified_gmt":"2020-08-08T11:42:11","slug":"arhitektura-s3-3-goda-evolyuczii-mail-ru-cloud-storage","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/arhitektura-s3-3-goda-evolyuczii-mail-ru-cloud-storage","title":{"rendered":"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/a53775776b3fc969cc15c9d13a64039d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em><noindex><a rel=\"nofollow\" href=\"https:\/\/www.deviantart.com\/st-pete\/art\/Storage-Corridor-408874509\">Corredor de Almacenamiento<\/a><\/noindex> por St-Pete<\/em><\/p>\n<p><\/p>\n<p>\u00a1Hola a todos! Soy Mons Anderson, arquitecto de la plataforma <noindex><a rel=\"nofollow\" href=\"https:\/\/mcs.mail.ru\/\">Soluciones en la Nube de Mail.ru<\/a><\/noindex>, les contar\u00e9 c\u00f3mo construimos nuestro almacenamiento S3, c\u00f3mo funciona, qu\u00e9 soluciones resultaron exitosas y cu\u00e1les deber\u00edamos modificar si comenz\u00e1ramos un proyecto similar desde cero hoy.<\/p>\n<p><\/p>\n<p>Este art\u00edculo fue preparado sobre la base de una presentaci\u00f3n en <noindex><a rel=\"nofollow\" href=\"https:\/\/corp.mail.ru\/ru\/press\/events\/databases-2\/\">@Databases Meetup<\/a><\/noindex> por Mail.ru Cloud Solutions &amp; Tarantool. En el art\u00edculo hablaremos de:<\/p>\n<p><\/p>\n<ul>\n<li>c\u00f3mo estaba estructurado el almacenamiento de Mail.ru, sobre el cual construimos el almacenamiento S3;<\/li>\n<li>qu\u00e9 a\u00f1adimos para crear Mail.ru Cloud Storage;<\/li>\n<li>c\u00f3mo funciona el modelo de almacenamiento de objetos y qu\u00e9 pasos se dieron para lanzarlo a producci\u00f3n;<\/li>\n<li>sobre ajustes del sistema en producci\u00f3n: conmutaci\u00f3n por error y escalado;<\/li>\n<li>c\u00f3mo implementamos el particionamiento y re-particionamiento;<\/li>\n<li>as\u00ed como sobre el trabajo con certificados SSL.<\/li>\n<\/ul>\n<p><\/p>\n<p>Si no quieres leer, puedes <noindex><a rel=\"nofollow\" href=\"https:\/\/youtu.be\/NEgm1nsv-qg\">ver<\/a><\/noindex>.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2 id=\"kak-bylo-ustroeno-hranilische-mailru-poverh-kotorogo-my-stroili-s3-hranilische\">C\u00f3mo estaba estructurado el almacenamiento de Mail.ru, sobre el cual construimos el almacenamiento S3<\/h2>\n<p><\/p>\n<p>El desarrollo de nuestro S3 comenz\u00f3 sobre el almacenamiento de Mail.ru Cloud, por lo que primero vale la pena contar c\u00f3mo est\u00e1 estructurado y qu\u00e9 capacidades tiene.<\/p>\n<p><\/p>\n<p>El almacenamiento de Mail.ru Cloud consiste en servidores con discos. En promedio, un servidor de almacenamiento moderno tiene 36 discos de 12 a 14 terabytes. Antes los discos eran m\u00e1s peque\u00f1os, pero en tres a\u00f1os su capacidad ha crecido y hoy en d\u00eda casi alcanza medio petabyte de datos en bruto. <\/p>\n<p><\/p>\n<p>Los discos de diferentes servidores de almacenamiento se combinan en lo que se llama \"pares\" (pair). Un par es una unidad \u00fanica de almacenamiento de archivos. En esencia, es un disco montado en una partici\u00f3n determinada en una ruta espec\u00edfica, donde pueden residir los archivos identificados por hashes. <\/p>\n<p><\/p>\n<p>El par es un nombre hist\u00f3rico que ha perdurado hasta hoy, aunque en un par no necesariamente hay solo dos discos. Pueden ser tres discos o diferentes tipos de almacenamiento h\u00edbrido, por ejemplo, 3\/2. <\/p>\n<p>\n<img decoding=\"async\" alt=\"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/544ab79846539262e2d4dff6ab95ffff.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><em>Pares (pair) \u2014 unidades de almacenamiento de objetos<\/em><\/p>\n<p><\/p>\n<p>Todos los pares se almacenan en PairDB \u2014 una aplicaci\u00f3n basada en Tarantool. Todas las bases en nuestro almacenamiento, desde las m\u00e1s antiguas, son Tarantool, no utilizamos otras bases.<\/p>\n<p><\/p>\n<p>PairDB almacena todos los pares, sus estados, el espacio libre, las capacidades de fallo, los \u00faltimos errores. Tambi\u00e9n puede por s\u00ed misma consultar a los pares, actualizar su estado, verificar si est\u00e1n funcionando o no. Es decir, PairDB proporciona una visi\u00f3n general del estado de todos los discos de nuestro sistema.<\/p>\n<p>\n<img decoding=\"async\" alt=\"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/d50781b8b51ed5fe126bc84e19c934d1.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><em>Pair DB: base de datos con el estado de los pares<\/em><\/p>\n<p><\/p>\n<p>En los pares se almacenan archivos, y para saber qu\u00e9 archivo est\u00e1 en qu\u00e9 par, se necesita otra base de datos: FileDB. Esta almacena el mapeo, la definici\u00f3n de correspondencia: el archivo tal se almacena en el par tal, as\u00ed como una peque\u00f1a cantidad de atributos necesarios.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/b1a64737cf7f916bff446c10c1f01d4c.jpeg\" style=\"display:block;margin: 0 auto;\" \/><em>File DB: el lugar donde se almacena el archivo<\/em><\/p>\n<p>Otro eslab\u00f3n importante es el servicio Nylon, un enrutador para trabajar con bases de datos. Es un \u00fanico punto de entrada que permite trabajar a trav\u00e9s de una interfaz \u00fanica tanto con PairDB como con FileDB. Es un servicio sin estado, realiza el balanceo de solicitudes, entiende a qu\u00e9 shard de FileDB se debe acceder, y sabe qu\u00e9 pares est\u00e1n activos y cu\u00e1les no.<\/p>\n<p>\n<img decoding=\"async\" alt=\"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/3e2225f229c8cfa462d620d2b5fb581e.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><em>Nylon: enrutador para trabajar con bases de datos<\/em><\/p>\n<p><\/p>\n<p>Tambi\u00e9n es necesario de alguna manera almacenar contenido en el repositorio. Para esto existe un servicio: Streamer. Proporciona dos m\u00e9todos HTTP: el m\u00e9todo PUT para cargar contenido en el repositorio y el m\u00e9todo GET para recuperar contenido de all\u00ed. HTTP es un protocolo bastante popular y conveniente para la transferencia de datos. <\/p>\n<p><\/p>\n<p>Cuando nos dirigimos a Streamer, \u00e9ste se comunica a trav\u00e9s de Nylon con PairDB, determina a qu\u00e9 par se puede cargar el archivo y luego transfiere los datos por WebDAV a ese par. <\/p>\n<p><\/p>\n<p>En esencia, cualquier servidor de almacenamiento es nginx m\u00e1s discos montados en rutas espec\u00edficas. Podemos cargar un archivo en el repositorio desde Streamer, eliminarlo, renombrarlo o verificar su integridad. Es decir, es una interfaz conveniente para la interacci\u00f3n de bajo nivel con el almacenamiento. <\/p>\n<p>\n<img decoding=\"async\" alt=\"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/3722a89ed44cace36e9cb1f8bee4bd1e.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><em>Streamer: punto de entrada al almacenamiento<\/em><\/p>\n<p><\/p>\n<h2 id=\"chto-my-dobavili-chtoby-sdelat-s3-hranilische\">Qu\u00e9 hemos a\u00f1adido para crear almacenamiento S3<\/h2>\n<p><\/p>\n<p>As\u00ed que hemos revisado la estructura b\u00e1sica del almacenamiento en el momento en que nos prepar\u00e1bamos para lanzar el almacenamiento S3. Con el m\u00e9todo PUT pod\u00edamos colocar contenido arbitrario all\u00ed y obtener como identificador de esos datos un hash. Con este identificador, posteriormente se pod\u00eda ir a recuperar el archivo original. Pero esto no es suficiente para implementar S3. En el protocolo S3, adem\u00e1s del almacenamiento de objetos, existen:<\/p>\n<p><\/p>\n<ul>\n<li>almacenamiento de metadatos: propiedades adicionales de los objetos;<\/li>\n<li>organizaci\u00f3n del acceso a los objetos a trav\u00e9s de HTTP;<\/li>\n<li>agrupaci\u00f3n de objetos en colecciones: buckets;<\/li>\n<li>HTTP-S3 Endpoint. S3 organiza los datos en estructuras definidas: buckets, cada uno de los cuales proporciona un punto de entrada para el almacenamiento de archivos.<\/li>\n<\/ul>\n<p><\/p>\n<p>Para implementar esta l\u00f3gica, fue necesario contar con un servicio separado. Tambi\u00e9n quer\u00edamos prever desde el principio una arquitectura para el crecimiento futuro del servicio con escalabilidad lineal.<\/p>\n<p><\/p>\n<h2 id=\"pervye-komponenty\">Primeros componentes<\/h2>\n<p><\/p>\n<p>El demonio que implementa la API S3. Esta es la API est\u00e1ndar S3 de Amazon, que soporta el trabajo con XML para metadatos y permite transmitir contenido directamente. No tuvimos que inventar nada, todo est\u00e1 descrito y documentado.<\/p>\n<p><\/p>\n<p>Tambi\u00e9n colocamos Nginx delante del servicio. Lo utilizamos para la terminaci\u00f3n de SSL, balanceo de carga y algo de l\u00f3gica en Lua (m\u00e9tricas, registro y trazabilidad).<\/p>\n<p><\/p>\n<p>Para el almacenamiento de metadatos S3, tambi\u00e9n elegimos Tarantool. En la primera versi\u00f3n, el demonio S3 acced\u00eda a esta base de datos para metadatos, mientras que el contenido se almacenaba en un gran almacenamiento a trav\u00e9s de Streamer.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/03dddec282b5bb41eb63748ccfb6c9a4.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Nginx + API S3 + metadatos<\/em><\/p>\n<p><\/p>\n<h2 id=\"obektnaya-model-hraneniya\">Modelo de objeto de almacenamiento<\/h2>\n<p><\/p>\n<p>Veamos c\u00f3mo funciona S3. El usuario puede crear un bucket: una colecci\u00f3n de objetos. El bucket se dirige por el nombre del host y es un subdominio del servicio. Dentro del bucket, el usuario puede crear objetos. El identificador del objeto ser\u00e1 la URL. El contenido del objeto es un blob, un arreglo de datos binarios que almacenaremos en el almacenamiento. Tambi\u00e9n el objeto tiene atributos: el nombre \u2014 esa misma URL, ACL (lista de control de acceso), otros atributos adicionales o arbitrarios \u2014 todo esto se guarda en los metadatos. <\/p>\n<p><\/p>\n<p>El esquema normalizado de estos datos podr\u00eda verse as\u00ed: hay proyectos que poseen los buckets, que a su vez contienen los objetos, y los objetos pueden ser compuestos. Dado que uno de los m\u00e9todos para cargar un objeto es por partes, hay dos tablas auxiliares para la carga: uploads y chunks. Adem\u00e1s, los proyectos tienen credenciales de acceso y facturaci\u00f3n. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/e2bede45ba4044f658b47a9840fd5224.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Esquema de datos<\/em><\/p>\n<p><\/p>\n<p>Dado que est\u00e1bamos creando un servicio B2B con acceso de pago, este esquema necesitaba facturaci\u00f3n.<br \/>\nEl servicio de facturaci\u00f3n tambi\u00e9n lo implementamos en Tarantool. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/d5b1a63e2273e933c95deecdb054bfe6.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h2 id=\"dorabotki-s3-hranilischa-shagi-k-prodakshenu\">Mejoras en el almacenamiento S3: pasos hacia la producci\u00f3n<\/h2>\n<p><\/p>\n<p>Ya hemos creado un modelo funcional que se puede usar: los objetos y metadatos se almacenaron, pero faltaban algunos detalles para su salida a producci\u00f3n.<\/p>\n<p><\/p>\n<p>En primer lugar, el sistema de l\u00edmites de tasa. Si se inicia el servicio sin \u00e9l, podr\u00edamos sobrecargar impredeciblemente alguna parte del sistema durante picos de carga. El l\u00edmite de tasa debe funcionar as\u00ed: cualquier solicitud S3 llega a un host espec\u00edfico, este host es el identificador del bucket, y el bucket pertenece a un cliente determinado. Necesitamos definir alguna funci\u00f3n para el bucket que permita calcular el l\u00edmite de tasa. <\/p>\n<p><\/p>\n<p>Adem\u00e1s, el sistema de l\u00edmites de tasa debe ser lo suficientemente eficiente como para soportar la carga que llega a S3.<\/p>\n<p><\/p>\n<p>Aqu\u00ed volvimos a usar Tarantool. Los l\u00edmites de tasa son un cl\u00faster de 21 instancias, las instancias se dividen en grupos, se distribuyen en tres nodos f\u00edsicos y se unen en un gran cl\u00faster topol\u00f3gico. Los cambios de configuraci\u00f3n se propagan autom\u00e1ticamente: se establecen l\u00edmites de tasa, valores predeterminados y configuraci\u00f3n. Cada bucket es atendido estrictamente por una sola instancia. Cuando llega una solicitud a un bucket espec\u00edfico, se calcula la instancia responsable de ese bucket. Dentro de este nodo, se contabiliza la tasa actual de solicitudes mediante un algoritmo similar al Token Bucket. Luego, el sistema de l\u00edmites de tasa, basado en los indicadores actuales de carga y las propiedades establecidas para el bucket espec\u00edfico, determina si se puede realizar la solicitud o no. La verificaci\u00f3n de l\u00edmites se realiza en la etapa m\u00e1s temprana de la ejecuci\u00f3n de la solicitud S3, protegiendo todos los dem\u00e1s elementos del sistema de una sobrecarga excesiva. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/1b91e5d1fe067c859ba9b36d58827579.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Adem\u00e1s, con carga es bastante dif\u00edcil prescindir de la cach\u00e9. En S3 se espera un acceso repetido a los mismos objetos, es decir, es un almacenamiento caliente. En condiciones normales, el acceso a un \u00fanico archivo es atendido por toda la cadena: Streamer, FileDB, PairDB, Storage. Pero al acceder repetidamente a un archivo, optimizamos el acceso a este contenido mediante una cach\u00e9 local.<\/p>\n<p><\/p>\n<p>La cach\u00e9 es multicapa y se implementa mediante nginx, discos SSD locales y de RAM. Aqu\u00ed no utilizamos Tarantool, porque es m\u00e1s conveniente entregar objetos desde el sistema de archivos, as\u00ed podemos hacer un escalonamiento de la cach\u00e9. Adem\u00e1s, tenemos objetos grandes con un tama\u00f1o m\u00e1ximo de 32 gigabytes, y en Tarantool solo se pueden almacenar en cach\u00e9 objetos peque\u00f1os.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/faa02bd52a1d70642589d775f22c5e75.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Este fue el primer sistema con el que iniciamos, ten\u00eda una capacidad calculada, suficiente para investigar y comprender el producto y asegurarnos de que funcionara. <\/p>\n<p><\/p>\n<h2 id=\"dorabotki-boevoy-sistemy-feylover-i-masshtabirovanie\">Mejoras del sistema en producci\u00f3n: failover y escalabilidad<\/h2>\n<p><\/p>\n<p>El sistema ya estaba en funcionamiento, pero al principio nos falt\u00f3 algo: era necesario a\u00f1adir failover y escalabilidad. <\/p>\n<p><\/p>\n<p>Nuestro demonio S3 obten\u00eda metadatos a trav\u00e9s del protocolo Tarantool. Reemplazamos la base de datos original con Tarantool, que actuaba como un enrutador proxy para las solicitudes de metadatos. Desde el punto de vista de la aplicaci\u00f3n que implementa la API, nada cambi\u00f3: continu\u00f3 accediendo a la base de datos a trav\u00e9s del protocolo Tarantool, pero el enrutador pudo asegurar un failover activo. Esto significa que pudimos verificar la disponibilidad de los nodos, manejar pausas durante los cambios y fallos, etc. Adem\u00e1s, no modificamos la aplicaci\u00f3n en s\u00ed. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/978ff8a458f8d48b98672121cf6eca5d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h2 id=\"podrobnee-o-tom-kak-my-realizovali-shardirovanie\">M\u00e1s sobre c\u00f3mo implementamos el sharding<\/h2>\n<p><\/p>\n<p>La siguiente cuesti\u00f3n a la que tuvimos que atender fue el sharding. El sistema estaba creciendo, aumentando la cantidad de objetos, y necesit\u00e1bamos expandir nuestras capacidades para un mayor crecimiento.<\/p>\n<p><\/p>\n<p>Regresando al esquema de datos: hay proyectos, hay buckets, credenciales y facturaci\u00f3n. Estos son objetos que con alta probabilidad en el futuro cercano no superar\u00e1n un solo instancia ni en volumen ni en solicitudes. Por lo tanto, no tiene sentido hacer sharding, y los hemos trasladado a una instancia separada que permanecer\u00e1 sin sharding. Esto permite una gesti\u00f3n m\u00e1s coherente de proyectos y buckets, ya que hay un \u00fanico punto no shardado. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/c5a1c1a875e756e3dceb5f885fbda2c8.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Tambi\u00e9n en el esquema hay objetos que crecen linealmente: al principio eran cientos de miles, ahora su cantidad se mide en varios miles de millones. Tales objetos, junto con sus partes, necesitaban ser trasladados a un cl\u00faster shardado. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/00bb418cc61ad2e3e8797caf5d1ab202.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Dividimos el esquema, pero los objetos necesitan trabajar con los buckets: un objeto siempre pertenece a un bucket espec\u00edfico, adem\u00e1s de que en el bucket hay ACL. Por lo tanto, para cada shard de objetos mantenemos una copia sombra de cada bucket. Adem\u00e1s, durante la modificaci\u00f3n de objetos y la ejecuci\u00f3n de consultas, es necesario contar el volumen para la facturaci\u00f3n, por lo que cada shard tiene contadores de facturaci\u00f3n.<\/p>\n<p><\/p>\n<p>Tambi\u00e9n a\u00f1adimos varias tablas y componentes m\u00e1s:<\/p>\n<p><\/p>\n<ul>\n<li>una papelera, para eliminar proyectos antiguos que son eliminados o congelados;<\/li>\n<li>cola para tareas en segundo plano, es decir, el almacenamiento principal puede realizar tareas en segundo plano que necesitan hacerse en el cl\u00faster;<\/li>\n<li>soporte del ciclo de vida: un mecanismo que permite trabajar con objetos y gestionar su ciclo de vida.<\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/933e98dc559eb8e6bac14003215a6836.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Como parte de los datos la trasladamos a los shards, se necesit\u00f3 un proxy de sharding. Podr\u00edamos haber reutilizado el enrutador para este prop\u00f3sito, pero un proxy de sharding separado, encargado \u00fanicamente de sharding de datos, permite acceder a los datos desde el enrutador en su totalidad, sin pensar en c\u00f3mo se dividen.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/4b181ed4629180e15558f25b1e4d5718.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Voy a contar por qu\u00e9 no tomamos una soluci\u00f3n lista, sino que quer\u00edamos hacer una funci\u00f3n de sharding personalizada. <\/p>\n<p><\/p>\n<p>Veamos c\u00f3mo est\u00e1 estructurada. Tenemos 256 shards disponibles. Para cada bucket, asignamos un rango utilizando alguna funci\u00f3n consistente. Es simple \u2014 as\u00ed como utilizas una funci\u00f3n consistente para determinar la pertenencia a un shard, determinas el shard inicial y asignas el rango:<\/p>\n<p><\/p>\n<p><code>f(bucket, shards) = subset<\/code><\/p>\n<p><\/p>\n<p>Es decir, si tomas un bucket, puedes decir que \u00e9l y sus datos siempre estar\u00e1n en un subconjunto espec\u00edfico de todos los shards. Esto reduce el impacto de ciertos buckets sobre otros y simplifica el trabajo de las consultas map-reduce, cuando necesitas, por ejemplo, listar los objetos en un bucket. Para ello, es necesario interrogar todos los shards donde se almacenan estos objetos. Si los objetos estuvieran en todos los shards, cualquier listado afectar\u00eda al sistema en su totalidad, mientras que aqu\u00ed solo afecta a un subconjunto espec\u00edfico.<\/p>\n<p><\/p>\n<p>Adem\u00e1s, cada objeto pertenece a un bucket espec\u00edfico, por lo que cuando solicitamos un objeto, lo hacemos por su nombre en un bucket espec\u00edfico. Es decir, podemos definir una funci\u00f3n para el objeto no desde todo el rango disponible de shards, sino solo desde el subconjunto de su bucket:<\/p>\n<p><\/p>\n<p><code>f(object, subset) = shard<\/code><\/p>\n<p><\/p>\n<p>Tomamos un objeto espec\u00edfico, y como argumentos de la funci\u00f3n pasamos no todos los shards, sino el subconjunto de su bucket \u2014 y obtenemos un shard espec\u00edfico. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/10480ad2430c228c511ff3cdc5071596.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>As\u00ed que el sharding est\u00e1 implementado, hay un proxy de sharding. A partir de aqu\u00ed, solo queda que el enrutador y la base de datos de metadatos accedan al proxy de sharding. Por ejemplo, para crear objetos de copias de sombras \u2014 cuando creamos un bucket, el almacenamiento principal debe crear un representante de este bucket en todos los shards donde debe estar presente.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/bb34d1f747903a3c2f08f582e4424787.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h2 id=\"kak-my-realizovali-resharding\">C\u00f3mo implementamos el resharding<\/h2>\n<p><\/p>\n<p>El mayor problema del sharding es el resharding. Era importante para nosotros hacerlo sin tiempo de inactividad, ya que el sistema ya estaba en producci\u00f3n. Mostrar\u00e9 c\u00f3mo resolvimos el problema mediante un ejemplo de una tarea similar con la migraci\u00f3n en vivo de datos de un proyecto a otro.<\/p>\n<p><\/p>\n<p>A continuaci\u00f3n se muestra el esquema de nuestro cl\u00faster que result\u00f3 despu\u00e9s de implementar el sharding. Tenemos nginx, S3 API, un enrutador, una base de datos primaria con proyectos, un proxy de sharding y los shards en s\u00ed.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/0e6bd16c7fc47437b3b7d96b6d9809a4.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Anteriormente mencion\u00e9 que en una etapa del proyecto hab\u00eda una tarea de producto: 'Lanzar otro almacenamiento, Icebox, como Hotbox, solo que para datos fr\u00edos'. En esencia, es un almacenamiento similar, pero con diferentes URL y sin cach\u00e9s.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/9ce9085e1d03e9a99b6b8ccc0717c653.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Icebox se usaba menos que Hotbox, por lo que durante bastante tiempo funcion\u00f3 sin ning\u00fan tipo de sharding. Al final, decidimos abandonarlo y combinar Hotbox e Icebox en un solo servicio, simplemente separando las clases de almacenamiento. <\/p>\n<p><\/p>\n<p>Los buckets en los almacenes no se cruzaban, se pod\u00edan fusionar y mover f\u00e1cilmente, pero los clientes utilizaban ambos almacenes, lo que significaba que deb\u00edamos resolver el problema de la ausencia de tiempo de inactividad. No pod\u00edamos simplemente apagar y copiar. Realizamos la migraci\u00f3n en varias etapas.<\/p>\n<p><\/p>\n<p>Para empezar, sincronizamos los almacenes primarios. Ten\u00edamos Tarantool y pod\u00edamos al crear un objeto hacer lo siguiente: <\/p>\n<p><\/p>\n<ul>\n<li>la base recibe una solicitud para crear un bucket, por ejemplo en Hotbox;<\/li>\n<li>Tarantool verifica en la otra base (en este caso, en Icebox) que no existe tal bucket;<\/li>\n<li>si el bucket existe, la base indica que no se puede crear, y se sincroniz\u00f3 como existente.<br \/>\n<img decoding=\"async\" alt=\"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/6694c9804f09942416c1717b455b9fd3.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Sincronizaci\u00f3n de buckets<\/em><\/li>\n<\/ul>\n<p><\/p>\n<p>En el almacenamiento que deb\u00eda recibir todos los datos, se introdujo para proyectos y buckets un indicador que dec\u00eda d\u00f3nde se almacenaba este objeto. Pod\u00eda almacenarse localmente, es decir, en Hotbox, en Icebox \u2014 entonces no hay datos en el nuevo almacenamiento, o pod\u00eda estar en estado de migraci\u00f3n.<\/p>\n<p><\/p>\n<p>Si un proyecto o bucket ten\u00eda el indicador Migrating, durante la migraci\u00f3n la solicitud se ejecutaba primero en el nuevo almacenamiento, donde deb\u00edan estar los datos, y si no estaban all\u00ed, las solicitudes se redirig\u00edan al almacenamiento alternativo.<\/p>\n<p><\/p>\n<p>Luego cambiamos el tr\u00e1fico. Dado que la API pod\u00eda atender tanto solicitudes de Icebox como de Hotbox, pudimos cambiar el tr\u00e1fico sin tiempo de inactividad, simplemente trasladando los hosts y agregando las entradas correspondientes en Nginx. <\/p>\n<p><\/p>\n<p>Despu\u00e9s de que el tr\u00e1fico fuera redirigido, se pudo eliminar Nginx y la API de Icebox.<br \/>\nLuego eliminamos Nginx de Icebox y la API de S3, y todo funcion\u00f3:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/62d9f960fc1f11b875a8f8a5aa8e8152.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>A continuaci\u00f3n, iniciamos un proceso de migraci\u00f3n en segundo plano, que funciona dentro de la base de datos: analiza elemento por elemento todos los proyectos y sus buckets, les asigna el estado de Migrando, transfiere los datos y, al finalizar la transferencia, asigna el estado de Local.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/1a3129136f7ccacfdcff260f10cb0605.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Despu\u00e9s de transferir los datos, ya no necesitamos el antiguo almacenamiento, por lo que eliminamos las partes restantes del antiguo sistema y quitamos del c\u00f3digo el soporte para el estado de migraci\u00f3n.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/13b6f11add40c21a3b9afc05dd0dfea9.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Siguiendo los mismos principios, se llev\u00f3 a cabo la resharding del antiguo almacenamiento al shardizado:<\/p>\n<p><\/p>\n<ul>\n<li>Marcamos todos los buckets como <code>No shardizado<\/code>. Todas las solicitudes a ellos se dirigieron al almacenamiento original, no shardizado.<\/li>\n<li>Los nuevos buckets se crearon directamente en estado <code>Shardizado<\/code>.<\/li>\n<li>. Se tomaba un bucket a la vez, se establec\u00eda el estado de <code>Migrando<\/code> y se transfer\u00edan los datos.<\/li>\n<\/ul>\n<p><\/p>\n<p>Las solicitudes se atend\u00edan seg\u00fan el principio:<\/p>\n<p><\/p>\n<ul>\n<li>Leemos en el nuevo, luego en el viejo.<\/li>\n<li>Creamos solo en el nuevo.<\/li>\n<li>Actualizamos en dos fases: si no est\u00e1 en el nuevo, transferimos del viejo al nuevo y luego actualizamos.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"rabota-s-ssl-sertifikatami\">Trabajo con certificados SSL<\/h2>\n<p><\/p>\n<blockquote><p>En el frontend utilizamos Nginx. En nuestro caso, no es un Nginx com\u00fan, sino OpenResty, Nginx con soporte para LuaJIT.<\/p><\/blockquote>\n<p>Otro componente del sistema es el manejo de certificados SSL. En el almacenamiento S3, puedes establecer tu propio dominio para acceder a un bucket espec\u00edfico, simplemente utilizando <code>Del lado del proveedor, es necesario crear un alias para todas las direcciones IP de la subred en un formato que redirija la solicitud al DNS del cliente.<\/code>. Pero hoy en d\u00eda no se puede prescindir de HTTPS: un dominio propio implica un certificado SSL propio. <\/p>\n<p><\/p>\n<p>Como ya mencion\u00e9, la balanceaci\u00f3n y terminaci\u00f3n de SSL est\u00e1n a cargo de Nginx. En nuestro caso, no es un Nginx com\u00fan, sino OpenResty, Nginx con soporte para LuaJIT.<\/p>\n<p><\/p>\n<p>Esto nos permiti\u00f3 ense\u00f1ar a nuestro Nginx a entregar certificados arbitrarios de manera bastante simple. Adem\u00e1s, necesit\u00e1bamos entregar certificados din\u00e1micamente (sin necesidad de escribirlos en un archivo de configuraci\u00f3n). Utilizamos la extensi\u00f3n <code>ssl_certificate_by_lua<\/code>, que permite leer el certificado de una fuente arbitraria durante el handshake de TLS. Como almacenamiento de certificados, tambi\u00e9n utilizamos Tarantool: esto permite gestionar los certificados desde el exterior y proporciona una entrega extremadamente r\u00e1pida.<\/p>\n<p><\/p>\n<p>Tambi\u00e9n se ha implementado un demonio separado, cuya tarea es actualizar regularmente los certificados emitidos mediante Let's Encrypt.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/8d61c1cb3084d9eb4eb8faa745e212db.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h2 id=\"chto-by-ya-sohranil-a-chto-sdelal-po-drugomu-esli-razrabatyvat-hranilische-zanovo\">Qu\u00e9 habr\u00eda conservado y qu\u00e9 har\u00eda de manera diferente si desarrollara el almacenamiento desde cero<\/h2>\n<p><\/p>\n<h3 id=\"chto-nuzhno-bylo-ispolzovat-s-samogo-nachala\">Qu\u00e9 deber\u00eda haberse utilizado desde el principio<\/h3>\n<p><\/p>\n<p><strong>Shardear desde el principio<\/strong>. Gener\u00f3 bastantes problemas hacer resharding. Es f\u00e1cil de hacer, pero a\u00fan as\u00ed, si se inician proyectos que necesitan escalar, es mejor optar desde el principio por un cl\u00faster shardado, aunque sea con un m\u00ednimo de nodos. La implementaci\u00f3n de sharding al inicio es casi gratuita en comparaci\u00f3n con la integraci\u00f3n de sharding en un sistema en funcionamiento.<\/p>\n<p><\/p>\n<p><strong>Trabajar con Tarantool a trav\u00e9s de balanceadores<\/strong>. Ahora conectamos todas las bases nuevas a trav\u00e9s de balanceadores desde el inicio. Esto permite expandir la funcionalidad y lograr una mayor resistencia a fallos. <\/p>\n<p><\/p>\n<p><strong>Auto failover<\/strong>. Instalar\u00eda todas las herramientas requeridas para el auto failover, ya que los primeros fracasos tras el lanzamiento estaban relacionados con su ausencia. Despu\u00e9s de la experiencia con S3, todos los productos posteriores se lanzaron teniendo esto en cuenta.<\/p>\n<p><\/p>\n<p><strong>Caracter\u00edstica de S3 'Versionado'<\/strong>. Al principio, parec\u00eda que esta funcionalidad no era muy demandada. Integrar esta posibilidad en la arquitectura de un sistema en funcionamiento es extremadamente complicado.<\/p>\n<p><\/p>\n<p><strong>Facturaci\u00f3n separada<\/strong>. La forma en que integramos la facturaci\u00f3n en nuestro sistema funcion\u00f3 bien al principio, pero con el tiempo comenz\u00f3 a entorpecer, habr\u00eda sido mejor configurarla como un servicio completamente separado.<\/p>\n<p><\/p>\n<h3 id=\"chto-bylo-udachnym-resheniem\">Cu\u00e1l fue una decisi\u00f3n exitosa<\/h3>\n<p><\/p>\n<p><strong>Modelo de datos<\/strong>. La historia ha demostrado que a medida que el servicio evolucionaba, coincidimos bastante bien con el modelo de datos de Amazon, por lo que podemos implementar las caracter\u00edsticas que existen all\u00ed.<\/p>\n<p><\/p>\n<p><strong>Esquema de sharding<\/strong>. Apoyar\u00eda un dise\u00f1o similar de sharding basado en rangos por buckets, ya que esto permite distribuir bien las solicitudes de diferentes buckets a trav\u00e9s de un gran cl\u00faster.<\/p>\n<p><\/p>\n<p><strong>Uso de Tarantool<\/strong>. Tarantool ayud\u00f3 considerablemente en el desarrollo y modificaci\u00f3n del servicio, trabajamos f\u00e1cilmente con los datos, transformamos y shardamos el almacenamiento, sin necesidad de subir al nivel de la aplicaci\u00f3n. <\/p>\n<p><\/p>\n<blockquote><p>Esta presentaci\u00f3n se pronunci\u00f3 por primera vez en <noindex><a rel=\"nofollow\" href=\"https:\/\/corp.mail.ru\/ru\/press\/events\/databases-2\/\">@Databases Meetup<\/a><\/noindex> by Mail.ru Cloud Solutions&amp;Tarantool. Ver <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=jM4hL2u6JM0&amp;list=PLQzTaxmOHjntyNRPWhaWHqlHp8UN_wgQ3\">videos<\/a><\/noindex> otras presentaciones y suscr\u00edbase a los anuncios de eventos en Telegram <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/k8s_mail\">Alrededor de Kubernetes en Mail.ru Group<\/a><\/noindex>.<\/p><\/blockquote>\n<p>Tambi\u00e9n puedes ver mi antigua presentaci\u00f3n sobre S3 o leer el art\u00edculo de mi colega sobre el almacenamiento en bloques.<\/p>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=O0iIADHgBVc\">Ingenier\u00eda inversa de la arquitectura de Amazon S3 y c\u00f3mo era el almacenamiento S3 de MCS hace 3 a\u00f1os<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/472694\/\">M\u00e1s que Ceph: almacenamiento en bloque de la nube MCS<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>Fuente: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/513356\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>Storage Corridor by St-Pete \u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u042f Mons Anderson, \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u043e\u0440 \u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b Mail.ru Cloud Solutions, \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443, \u043a\u0430\u043a \u043c\u044b \u043f\u043e\u0441\u0442\u0440\u043e\u0438\u043b\u0438 \u043d\u0430\u0448\u0435 S3-\u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0435, \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442, \u043a\u0430\u043a\u0438\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u043e\u043a\u0430\u0437\u0430\u043b\u0438\u0441\u044c \u0443\u0434\u0430\u0447\u043d\u044b\u043c\u0438, \u0430 \u043a\u0430\u043a\u0438\u0435 \u0441\u0442\u043e\u0438\u043b\u043e \u0438\u0437\u043c\u0435\u043d\u0438\u0442\u044c, \u0435\u0441\u043b\u0438 \u0431\u044b \u043c\u044b \u043d\u0430\u0447\u0430\u043b\u0438 \u0442\u0430\u043a\u043e\u0439 \u0436\u0435 \u043f\u0440\u043e\u0435\u043a\u0442 \u0441 \u043d\u0443\u043b\u044f \u0441\u0435\u0439\u0447\u0430\u0441. \u0421\u0442\u0430\u0442\u044c\u044f \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u043b\u0435\u043d\u0430 \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0435 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u043d\u0430 @Databases Meetup by Mail.ru Cloud Solutions &amp; Tarantool. [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91091,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91090","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/arhitektura-s3-3-goda-evolyuczii-mail-ru-cloud-storage\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0410\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0430 S3: 3 \u0433\u043e\u0434\u0430 \u044d\u0432\u043e\u043b\u044e\u0446\u0438\u0438 Mail.ru Cloud Storage | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/arhitektura-s3-3-goda-evolyuczii-mail-ru-cloud-storage\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-08-08T11:42:11+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-08-08T11:42:11+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Arquitectura S3: 3 a\u00f1os de evoluci\u00f3n de Mail.ru Cloud Storage | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/arhitektura-s3-3-goda-evolyuczii-mail-ru-cloud-storage","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0410\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0430 S3: 3 \u0433\u043e\u0434\u0430 \u044d\u0432\u043e\u043b\u044e\u0446\u0438\u0438 Mail.ru Cloud Storage | ProHoster","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/arhitektura-s3-3-goda-evolyuczii-mail-ru-cloud-storage","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-08-08T11:42:11+00:00","article:modified_time":"2020-08-08T11:42:11+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"91090","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 12:34:25","updated":"2022-10-02 13:27:50","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/91090","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=91090"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/91090\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/91091"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=91090"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=91090"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=91090"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}