{"id":89160,"date":"2022-04-13T12:53:24","date_gmt":"2022-04-13T12:53:24","guid":{"rendered":"https:\/\/teknomers.com\/es\/recuperacion-ante-desastres-entre-regiones-con-elasticsearch\/"},"modified":"2022-04-13T12:53:24","modified_gmt":"2022-04-13T12:53:24","slug":"recuperacion-ante-desastres-entre-regiones-con-elasticsearch","status":"publish","type":"post","link":"https:\/\/teknomers.com\/es\/recuperacion-ante-desastres-entre-regiones-con-elasticsearch\/","title":{"rendered":"Recuperaci\u00f3n ante desastres entre regiones con Elasticsearch"},"content":{"rendered":"


\n<\/p>\n

\n
\"Recuperaci\u00f3n<\/div>\n

Como era de esperar, aqu\u00ed en Rebobinar<\/a>, tenemos muchos datos que proteger (m\u00e1s de 2 petabytes). Una de las bases de datos que utilizamos se llama Elasticsearch (ES u Opensearch, como se le conoce actualmente en AWS). En pocas palabras, ES es una base de datos de documentos que facilita resultados de b\u00fasqueda ultrarr\u00e1pidos. La velocidad es esencial cuando los clientes buscan un archivo o elemento en particular que necesitan restaurar usando Rebobinar<\/a>. Cada segundo de tiempo de inactividad cuenta, por lo que nuestros resultados de b\u00fasqueda deben ser r\u00e1pidos, precisos y confiables.<\/p>\n

Otra consideraci\u00f3n fue el desastre. recuperaci\u00f3n<\/a>. como parte de nuestro Controles de sistemas y organizaciones de nivel 2 (SOC2)<\/a> proceso de certificaci\u00f3n, necesit\u00e1bamos asegurarnos de tener un plan de recuperaci\u00f3n ante desastres que funcionara para restaurar el servicio en el improbable caso de que toda la regi\u00f3n de AWS estuviera inactiva.<\/p>\n

“\u00bfToda una regi\u00f3n de AWS? \u00a1Eso nunca suceder\u00e1!” (Excepto por cuando lo hizo<\/a>) <\/p>\n

Todo es posible, las cosas salen mal y, para cumplir con nuestros requisitos de SOC2, necesit\u00e1bamos tener una soluci\u00f3n que funcionara. Espec\u00edficamente, lo que necesit\u00e1bamos era una forma de replicar los datos de nuestros clientes de manera segura, eficiente y rentable en una regi\u00f3n alternativa de AWS. La respuesta fue hacer lo que Rewind hace tan bien: \u00a1hacer una copia de seguridad!<\/p>\n

Analicemos c\u00f3mo funciona Elasticsearch, c\u00f3mo lo usamos para respaldar datos de forma segura y nuestro proceso actual de recuperaci\u00f3n ante desastres.<\/p>\n

Instant\u00e1neas<\/strong><\/h2>\n

Primero, necesitaremos una lecci\u00f3n r\u00e1pida de vocabulario. Las copias de seguridad en ES se llaman instant\u00e1neas<\/em>. Las instant\u00e1neas se almacenan en un repositorio de instant\u00e1neas<\/em>. Hay m\u00faltiples tipos de repositorios de instant\u00e1neas<\/a>, incluido uno respaldado por AWS S3. Dado que S3 tiene la capacidad de replicar su contenido en un dep\u00f3sito en otra regi\u00f3n, fue una soluci\u00f3n perfecta para este problema en particular.<\/p>\n

AWS ES viene con un repositorio de instant\u00e1neas automatizado prehabilitado para usted. El repositorio est\u00e1 configurado de forma predeterminada para tomar instant\u00e1neas cada hora y no puede cambiar nada al respecto. Esto fue un problema para nosotros porque quer\u00edamos un diario<\/em> instant\u00e1nea enviada a un repositorio respaldado por uno de nuestros propios dep\u00f3sitos S3, que se configur\u00f3 para replicar su contenido en otra regi\u00f3n.<\/p>\n\n\n\n\n
\"\"<\/td>\n<\/tr>\n
Lista de instant\u00e1neas automatizadas GET _cat\/snapshots\/cs-automated-enc?v&s=id<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Nuestra \u00fanica opci\u00f3n era crear y administrar nuestro propio repositorio de instant\u00e1neas e instant\u00e1neas.<\/p>\n

Mantener nuestro propio repositorio de instant\u00e1neas no era ideal y parec\u00eda mucho trabajo innecesario. No quer\u00edamos reinventar la rueda, as\u00ed que buscamos una herramienta existente que hiciera el trabajo pesado por nosotros. <\/p>\n

Gesti\u00f3n del ciclo de vida de instant\u00e1neas (SLM)<\/strong><\/h2>\n

La primera herramienta que probamos fue la de Elastic Gesti\u00f3n del ciclo de vida de instant\u00e1neas (SLM)<\/a>una caracter\u00edstica que se describe como:<\/p>\n

La forma m\u00e1s f\u00e1cil de realizar copias de seguridad peri\u00f3dicas de un cl\u00faster. Una pol\u00edtica de SLM toma instant\u00e1neas autom\u00e1ticamente en un horario preestablecido. La pol\u00edtica tambi\u00e9n puede eliminar instant\u00e1neas seg\u00fan las reglas de retenci\u00f3n que defina.<\/em><\/p>\n

Incluso puede usar su propio repositorio de instant\u00e1neas. Sin embargo, tan pronto como intentamos configurar esto en nuestros dominios, fall\u00f3. R\u00e1pidamente aprendimos que AWS ES es una versi\u00f3n modificada de Elastic. co’s ES y que SLM no era compatible con AWS ES.<\/p>\n

Curador<\/strong><\/h4>\n

La siguiente herramienta que investigamos se llama Curador de Elasticsearch<\/a>. Era de c\u00f3digo abierto y mantenido por Elastic.co ellos mismos. <\/p>\n

Curator es simplemente una herramienta de Python que lo ayuda a administrar sus \u00edndices e instant\u00e1neas. Incluso tiene m\u00e9todos de ayuda para crear repositorios de instant\u00e1neas personalizados, lo cual fue una ventaja adicional.<\/p>\n

Decidimos ejecutar Curator como una funci\u00f3n de Lambda impulsada por una regla de EventBridge programada, todo empaquetado en AWS SAM.<\/p>\n

As\u00ed es como se ve la soluci\u00f3n final:<\/p>\n

\"\"<\/div>\n

ES Instant\u00e1nea Funci\u00f3n Lambda<\/strong><\/h2>\n

Lambda utiliza la herramienta Curator y es responsable de la administraci\u00f3n de instant\u00e1neas y repositorios. Aqu\u00ed hay un diagrama de la l\u00f3gica:<\/p>\n

\"\"<\/div>\n

Como puede ver arriba, es una soluci\u00f3n muy simple. Pero, para que funcionara, necesit\u00e1bamos que existieran un par de cosas:<\/p>\n