{"id":34841,"date":"2019-10-31T22:00:43","date_gmt":"2019-10-31T19:00:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible\/"},"modified":"2019-10-31T22:00:43","modified_gmt":"2019-10-31T19:00:43","slug":"avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible","title":{"rendered":"Automatizaci\u00f3n del reemplazo de discos con Ansible","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Automatizaci\u00f3n del reemplazo de discos con Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/c60a2326ab13e7766eafda3ae5ac39c5.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHola a todos. Soy administrador de sistemas principal en OK y soy responsable del funcionamiento estable del portal. Quiero contarles c\u00f3mo establecimos el proceso de reemplazo autom\u00e1tico de discos y luego c\u00f3mo excluimos al administrador de este proceso y lo reemplazamos con un bot.<\/p>\n<p>Este art\u00edculo es una especie de transliteraci\u00f3n <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=5WhbG3FQveE&amp;list=FLKN7KW1sxju7fWJvKuyKxEQ\">presentaci\u00f3n<\/a><\/noindex> en HighLoad+ 2018<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Construcci\u00f3n del proceso de reemplazo de discos<\/h2>\n<p><\/p>\n<h3>Primero, un poco de cifras<\/h3>\n<p>\nOK es un servicio gigantesco que utilizan millones de personas. Se opera con aproximadamente 7,000 servidores ubicados en 4 diferentes centros de datos. En los servidores hay m\u00e1s de 70,000 discos. Si los apilamos, tendr\u00edamos una torre de m\u00e1s de 1 km de altura. <\/p>\n<p>Los discos duros son el componente del servidor que m\u00e1s falla. Con estos vol\u00famenes, tenemos que reemplazar alrededor de 30 discos a la semana, y este procedimiento se ha convertido en una rutina no muy agradable.<\/p>\n<p><img decoding=\"async\" alt=\"Automatizaci\u00f3n del reemplazo de discos con Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/5e915e9077994efcc4e74a26fc6286fa.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Incidentes<\/h3>\n<p>\nEn nuestra empresa hemos implementado una gesti\u00f3n de incidentes completa. Cada incidente lo registramos en Jira, lo resolvemos y lo analizamos. Si un incidente afect\u00f3 a los usuarios, definitivamente nos reunimos y pensamos en c\u00f3mo reaccionar m\u00e1s r\u00e1pido en tales casos, c\u00f3mo reducir el impacto y, por supuesto, c\u00f3mo prevenir que suceda de nuevo.<\/p>\n<p>Los discos no son una excepci\u00f3n. Su estado es supervisado por Zabbix. Monitoreamos los mensajes en Syslog en busca de errores de lectura\/escritura, analizamos el estado de los arreglos HW\/SW, y seguimos SMART; para SSD, calculamos el desgaste. <\/p>\n<h3>C\u00f3mo se cambiaban los discos antes<\/h3>\n<p>\nCuando se activa alg\u00fan desencadenador en Zabbix, se crea un incidente en Jira y se asigna autom\u00e1ticamente a los ingenieros correspondientes en los centros de datos. Hacemos esto con todos los incidentes de hardware, es decir, aquellos que requieren alg\u00fan tipo de trabajo f\u00edsico con el equipo en el centro de datos. <br \/>\nEl ingeniero de centro de datos es la persona que resuelve problemas relacionados con el hardware, es responsable de la instalaci\u00f3n, mantenimiento y desmontaje de servidores. Al recibir un ticket, el ingeniero comienza a trabajar. En las estanter\u00edas, cambia los discos por s\u00ed mismo. Pero si no tiene acceso al dispositivo necesario, el ingeniero se dirige a los administradores de sistemas de guardia por ayuda. Primero, es necesario sacar el disco de rotaci\u00f3n. Para ello, hay que realizar los cambios necesarios en el servidor, detener las aplicaciones y desmontar el disco.<\/p>\n<p>El administrador del sistema de guardia es responsable del funcionamiento de todo el portal durante su turno laboral. Investiga incidentes, realiza reparaciones y ayuda a los desarrolladores con peque\u00f1as tareas. Sin embargo, no se encarga de los discos duros.<\/p>\n<p>Anteriormente, los ingenieros del centro de datos se comunicaban con el administrador del sistema a trav\u00e9s de un chat. Los ingenieros enviaban enlaces a tickets de Jira, el administrador los revisaba y manten\u00eda un registro de trabajos en alguna libreta. Pero este m\u00e9todo no era conveniente para tales tareas: la informaci\u00f3n no est\u00e1 estructurada y se pierde r\u00e1pidamente. Adem\u00e1s, el administrador pod\u00eda alejarse del ordenador y no responder durante un tiempo mientras el ingeniero estaba en el servidor con un mont\u00f3n de discos esperando.<\/p>\n<p>Pero lo peor era que los administradores no ten\u00edan una visi\u00f3n completa: no sab\u00edan qu\u00e9 incidentes relacionados con discos exist\u00edan ni d\u00f3nde podr\u00eda surgir un problema potencial. Esto se debe a que todos los incidentes de hardware los asignamos a los ingenieros. S\u00ed, se podr\u00eda mostrar todos los incidentes en el tablero del administrador. Pero son demasiados, y el administrador solo era involucrado en algunos de ellos.<\/p>\n<p>Adem\u00e1s, el ingeniero no pod\u00eda priorizar correctamente, ya que no sab\u00eda nada sobre la finalidad de los servidores espec\u00edficos ni sobre la distribuci\u00f3n de informaci\u00f3n en los dispositivos de almacenamiento.<\/p>\n<h3>Nuevo procedimiento para el reemplazo<\/h3>\n<p>\nLo primero que hicimos fue separar todos los incidentes de discos en un tipo diferente llamado \"HW-disco\" y a\u00f1adirle los campos \"nombre del dispositivo de bloques\", \"tama\u00f1o\" y \"tipo de disco\", para que esta informaci\u00f3n se guardara en el ticket y no tuvi\u00e9ramos que intercambiarla constantemente en el chat. <\/p>\n<p><img decoding=\"async\" alt=\"Automatizaci\u00f3n del reemplazo de discos con Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/c4526bf668e31d90e0fbd061de44f1a7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nTambi\u00e9n acordamos que, en un mismo incidente, solo cambiar\u00edamos un disco. Esto simplific\u00f3 considerablemente el proceso de automatizaci\u00f3n, la recopilaci\u00f3n de estad\u00edsticas y el trabajo en el futuro. <\/p>\n<p>Adem\u00e1s de esto, se a\u00f1adi\u00f3 un campo \"administrador responsable\". Ah\u00ed se asigna autom\u00e1ticamente el administrador de guardia. Esto es muy conveniente, porque ahora el ingeniero siempre ve qui\u00e9n es el responsable. No es necesario ir al calendario y buscar. Precisamente este campo permiti\u00f3 que se mostraran en el tablero del administrador los tickets en los que podr\u00eda necesitar su ayuda.<\/p>\n<p><img decoding=\"async\" alt=\"Automatizaci\u00f3n del reemplazo de discos con Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/5097e5dcca1fddd68d1e5f296c09f60a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nPara que todos los participantes obtengan el m\u00e1ximo beneficio de las innovaciones, creamos filtros y paneles, y se los explicamos a los chicos. Cuando las personas entienden los cambios, no se distancian de ellos como si fueran algo innecesario. Es importante para un ingeniero conocer el n\u00famero de la estanter\u00eda donde se encuentra el servidor, as\u00ed como el tama\u00f1o y tipo de disco. Un administrador necesita entender, en primer lugar, qu\u00e9 grupo de servidores es y qu\u00e9 efecto puede tener el reemplazo del disco.<\/p>\n<p>Tener campos y su visualizaci\u00f3n es pr\u00e1ctico, pero no nos ha liberado de la necesidad de utilizar chats. Para ello, tuvimos que cambiar el flujo de trabajo. <\/p>\n<p>Antes era as\u00ed:<\/p>\n<p><img decoding=\"async\" alt=\"Automatizaci\u00f3n del reemplazo de discos con Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/2b79cdb7ec88b5ae3d2917ad8b164c6d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nHoy en d\u00eda, as\u00ed siguen trabajando los ingenieros cuando no necesitan la ayuda de un administrador.<\/p>\n<p>Lo primero que hicimos fue introducir un nuevo estado <b>Investigar<\/b>. En este estado, el ticket se encuentra cuando el ingeniero a\u00fan no ha decidido si necesita o no un administrador. A trav\u00e9s de este estado, el ingeniero puede transferir el ticket al administrador. Adem\u00e1s, usamos este estado para marcar los tickets cuando se requiere el reemplazo del disco, pero el disco mismo no est\u00e1 disponible en el sitio. Esto ocurre en el caso de CDN y sitios remotos.<\/p>\n<p>Tambi\u00e9n agregamos el estado <b>Listo<\/b>. El ticket se transfiere a este estado despu\u00e9s de cambiar el disco. Es decir, todo ya est\u00e1 hecho, pero el HW\/SW RAID en el servidor se est\u00e1 sincronizando. Esto puede llevar bastante tiempo.<\/p>\n<p>Si se involucra a un administrador, el esquema se complica un poco.<\/p>\n<p><img decoding=\"async\" alt=\"Automatizaci\u00f3n del reemplazo de discos con Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/5b6aacbb0d4049e62e7cb9ee28eb6498.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nDesde el estado <b>Abrir<\/b> el ticket puede ser transferido tanto por el administrador del sistema como por el ingeniero. En el estado <b>En progreso<\/b> el administrador saca el disco de la rotaci\u00f3n para que el ingeniero pueda extraerlo f\u00e1cilmente: activa la luz, desmonta el disco, detiene las aplicaciones, dependiendo del grupo espec\u00edfico de servidores.<\/p>\n<p>Luego el ticket se transfiere a <b>Listo para cambiar<\/b>: esto es una se\u00f1al para el ingeniero de que el disco se puede retirar. Todos los campos en Jira ya est\u00e1n completados, el ingeniero sabe qu\u00e9 tipo y tama\u00f1o de disco es. Esta informaci\u00f3n se completa ya sea autom\u00e1ticamente en el estado anterior o por el administrador.<\/p>\n<p>Despu\u00e9s de cambiar el disco, el ticket se transfiere al estado <b>Cambiado<\/b>. Se verifica que se haya insertado el disco correcto, se hace la partici\u00f3n, se inicia la aplicaci\u00f3n y algunas tareas de recuperaci\u00f3n de datos. Adem\u00e1s, el ticket puede ser transferido al estado <b>Listo<\/b>, en este caso el responsable seguir\u00e1 siendo el administrador, ya que fue \u00e9l quien introdujo el disco en rotaci\u00f3n. El esquema completo se ve as\u00ed.<\/p>\n<p><img decoding=\"async\" alt=\"Automatizaci\u00f3n del reemplazo de discos con Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/32f8d488e2ff6a28a3341114b66de0a3.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nLa adici\u00f3n de nuevos campos nos ha facilitado mucho la vida. El equipo ahora trabaja con informaci\u00f3n estructurada, lo que hace claro qu\u00e9 y en qu\u00e9 etapa se debe hacer. Las prioridades son mucho m\u00e1s relevantes, ya que ahora las establece el administrador.<\/p>\n<p>Ya no es necesario hablar por chat. Por supuesto, el administrador puede escribir al ingeniero \"aqu\u00ed es necesario cambiarlo m\u00e1s r\u00e1pido\", o \"ya es tarde, \u00bfpodr\u00e1s realizar el cambio?\". Pero ya no nos comunicamos a diario en chats sobre estos temas.<\/p>\n<p>Los discos se est\u00e1n cambiando en lotes. Si el administrador llega al trabajo un poco antes, tiene tiempo libre y no ha ocurrido nada, puede preparar varios servidores para el cambio: asignar campos, sacar discos de rotaci\u00f3n y pasar la tarea al ingeniero. Un poco m\u00e1s tarde, el ingeniero llega al centro de datos, ve la tarea, recoge los dispositivos necesarios del almac\u00e9n y hace el cambio. Como resultado, la velocidad de reemplazo ha aumentado.<\/p>\n<h3>Experiencia adquirida en la creaci\u00f3n de Workflow.<\/h3>\n<p><\/p>\n<ul>\n<li><b>Al construir el procedimiento, es necesario recopilar informaci\u00f3n de diferentes fuentes.<\/b><br \/>\nAlgunos de nuestros administradores no sab\u00edan que el ingeniero cambia los discos por su cuenta. Algunos pensaban que la sincronizaci\u00f3n de MD RAID era monitoreada por ingenieros, aunque algunos de ellos ni siquiera ten\u00edan acceso para hacerlo. Algunos ingenieros s\u00e9niores lo hac\u00edan, pero no siempre, porque el proceso no estaba descrito en ninguna parte.<\/li>\n<li><b>El procedimiento debe ser simple y claro.<\/b><br \/>\nEs dif\u00edcil para una persona recordar muchos pasos. Los estados m\u00e1s importantes en Jira deben mostrarse en la pantalla principal. Se pueden renombrar, por ejemplo, In progress lo llamamos Ready to change. Y los dem\u00e1s estados se pueden ocultar en un men\u00fa desplegable, para que no distraigan. Pero es mejor no limitar a las personas, permitir que hagan la transici\u00f3n.<br \/>\nExplicar el valor de las innovaciones. Cuando las personas entienden, aceptan mejor el nuevo procedimiento. Para nosotros fue muy importante que las personas no solo hicieran clic en todo el proceso, sino que lo siguieran. Luego construimos la automatizaci\u00f3n sobre esa base.<\/li>\n<li><b>Esperar, analizar, comprender.<\/b><br \/>\nNos llev\u00f3 aproximadamente un mes construir el procedimiento, la implementaci\u00f3n t\u00e9cnica, realizar reuniones y discusiones. Y la implementaci\u00f3n dur\u00f3 m\u00e1s de tres meses. Vi c\u00f3mo la gente lentamente comenz\u00f3 a utilizar la nueva funci\u00f3n. En las primeras etapas hubo mucha negatividad. Pero no depend\u00eda en absoluto del procedimiento en s\u00ed ni de su implementaci\u00f3n t\u00e9cnica. Por ejemplo, un administrador utilizaba no Jira, sino un complemento de Jira en Confluence, y algunas cosas no estaban disponibles para \u00e9l. Le mostramos Jira, y la productividad del administrador mejor\u00f3 tanto en tareas generales como en el reemplazo de discos.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Automatizaci\u00f3n del reemplazo de discos<\/h2>\n<p>\nNos acercamos a la automatizaci\u00f3n del reemplazo de discos varias veces. Ya ten\u00edamos ciertos desarrollos, scripts, pero todos funcionaban ya sea en modo interactivo o manual y requer\u00edan ser iniciados. Y solo despu\u00e9s de implementar el nuevo procedimiento nos dimos cuenta de que precisamente eso nos hac\u00eda falta.<\/p>\n<p>Como ahora el proceso de reemplazo est\u00e1 dividido en etapas, con un responsable y una lista de acciones para cada una, podemos incorporar la automatizaci\u00f3n por etapas, en lugar de hacerlo todo de una vez. Por ejemplo, la etapa m\u00e1s simple - Ready (verificaci\u00f3n de la sincronizaci\u00f3n RAID\/datos) puede delegarse f\u00e1cilmente a un bot. Cuando el bot aprenda un poco, podemos asignarle una tarea m\u00e1s responsable: introducir el disco en rotaci\u00f3n, etc.<\/p>\n<h3>Un zool\u00f3gico de configuraciones<\/h3>\n<p>\nAntes de hablar del bot, hagamos una peque\u00f1a excursi\u00f3n a nuestro zool\u00f3gico de instalaciones. En primer lugar, esto se debe al tama\u00f1o gigantesco de nuestra infraestructura. En segundo lugar, para cada servicio tratamos de seleccionar la configuraci\u00f3n \u00f3ptima del hardware. Tenemos alrededor de 20 modelos de RAID de hardware, principalmente LSI y Adaptec, pero tambi\u00e9n hay HP y DELL de varias versiones. Cada controlador RAID tiene su propia utilidad de gesti\u00f3n. El conjunto de comandos y la salida pueden variar de versi\u00f3n a versi\u00f3n en cada controlador RAID. All\u00ed donde no se utilizan HW-RAID, puede haber mdraid.<\/p>\n<p>Pr\u00e1cticamente todas las nuevas instalaciones las hacemos sin redundancia de discos. Tratamos de no utilizar m\u00e1s RAID de hardware y software, ya que respaldamos nuestros sistemas a nivel de centros de datos y no de servidores. Pero, por supuesto, hay muchos servidores heredados que necesitan mantenimiento.<\/p>\n<p>En algunos casos, los discos en los controladores RAID se conectan como dispositivos en bruto, mientras que en otros se utilizan JBOD. Existen configuraciones con un solo disco del sistema en el servidor, y si es necesario reemplazarlo, se tiene que reinstalar el servidor con la instalaci\u00f3n del sistema operativo y las aplicaciones, incluyendo las mismas versiones, luego agregar los archivos de configuraci\u00f3n y ejecutar las aplicaciones. Tambi\u00e9n hay muchos grupos de servidores donde la redundancia no se realiza a nivel de subsistema de disco, sino directamente en las propias aplicaciones.<\/p>\n<p>En total, tenemos m\u00e1s de 400 grupos \u00fanicos de servidores que ejecutan alrededor de 100 aplicaciones diferentes. Para cubrir una cantidad tan enorme de opciones, necesit\u00e1bamos una herramienta de automatizaci\u00f3n multifuncional. Preferiblemente con un DSL simple, de modo que no solo pudiera ser mantenida por quien la escribi\u00f3.<\/p>\n<p>Elegimos Ansible porque es sin agente: no hab\u00eda necesidad de preparar la infraestructura, es de inicio r\u00e1pido. Adem\u00e1s, est\u00e1 escrito en Python, que es el est\u00e1ndar en el equipo.<\/p>\n<h3>Esquema general<\/h3>\n<p>\nVeamos un esquema general de automatizaci\u00f3n utilizando un ejemplo de un incidente. Zabbix detecta que el disco sdb ha fallado, se activa un disparador y se crea un ticket en Jira. El administrador lo revisa, se da cuenta de que no es un duplicado ni un falso positivo, es decir, que es necesario cambiar el disco, y mueve el ticket a En progreso.<\/p>\n<p><img decoding=\"async\" alt=\"Automatizaci\u00f3n del reemplazo de discos con Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/673df0fe9600bc65633841222f436d37.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nLa aplicaci\u00f3n DiskoBot, escrita en Python, consulta peri\u00f3dicamente Jira en busca de nuevos tickets. Observa que hay un nuevo ticket en progreso, se activa el hilo correspondiente que ejecuta el playbook en Ansible (esto se hace para cada estado en Jira). En este caso, se ejecuta Prepare2change.<\/p>\n<p>Ansible se env\u00eda al host, saca el disco de rotaci\u00f3n e informa el estado a la aplicaci\u00f3n a trav\u00e9s de Callbacks. <\/p>\n<p><img decoding=\"async\" alt=\"Automatizaci\u00f3n del reemplazo de discos con Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/8bfc13129f8deca640eb63ea81f616c7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nComo resultado, el bot mueve autom\u00e1ticamente el ticket a Listo para cambiar. El ingeniero recibe una notificaci\u00f3n y se dirige a cambiar el disco, despu\u00e9s de lo cual mueve el ticket a Cambiado. <\/p>\n<p><img decoding=\"async\" alt=\"Automatizaci\u00f3n del reemplazo de discos con Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/eeda06b6966f435e2172d3f9c61b341e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nSiguiendo el esquema descrito, el ticket regresa al bot, que ejecuta otro playbook, accede al host y pone el disco de nuevo en rotaci\u00f3n. El bot cierra el ticket. \u00a1Hurra!<\/p>\n<p><img decoding=\"async\" alt=\"Automatizaci\u00f3n del reemplazo de discos con Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/51b8c7050b0c10c16ad6a6d4974c3ebf.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nAhora hablemos de algunos componentes del sistema.<\/p>\n<h3>Diskobot<\/h3>\n<p>\nEsta aplicaci\u00f3n est\u00e1 escrita en Python. Selecciona tickets de Jira de acuerdo con JQL. Dependiendo del estado del ticket, este se asigna al manejador correspondiente, que a su vez ejecuta el playbook de Ansible correspondiente al estado.<\/p>\n<p>JQL y los intervalos de encuesta se definen en el archivo de configuraci\u00f3n de la aplicaci\u00f3n.<\/p>\n<pre><code class=\"plaintext\">jira_states:\n  investigate:\n    jql: '\u2026 status = Open and \"Disk Size\" is EMPTY'\n    interval: 180\n\n  inprogress:\n    jql: '\u2026  and \"Disk Size\" is not EMPTY and \"Device Name\" is not EMPTY'\n \n  ready:\n    jql: '\u2026 and (labels not in (\"dbot_ignore\") or labels is EMPTY)'\n    interval: 7200\n<\/code><\/pre>\n<p>\nPor ejemplo, entre los tickets en estado En progreso, se seleccionan solo aquellos cuyos campos Disk size y Device name est\u00e1n completos. Device name es el nombre del dispositivo de bloque necesario para ejecutar el playbook. Disk size es necesario para que el ingeniero sepa qu\u00e9 tama\u00f1o de disco se requiere.<\/p>\n<p>Y entre los tickets con estado Listo se filtran los tickets con la etiqueta dbot_ignore. Cabe mencionar que utilizamos las etiquetas de Jira tanto para este tipo de filtrado como para marcar tickets duplicados y recopilar estad\u00edsticas.<\/p>\n<p>En caso de fallo del playbook, Jira asigna la etiqueta dbot_failed para que se pueda investigar posteriormente. <\/p>\n<h3>Interacci\u00f3n con Ansible<\/h3>\n<p>\nLa aplicaci\u00f3n interact\u00faa con Ansible a trav\u00e9s de <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.ansible.com\/ansible\/latest\/dev_guide\/developing_api.html\">Ansible Python API<\/a><\/noindex>. En el playbook_executor pasamos el nombre del archivo y un conjunto de variables. Esto permite mantener el proyecto de Ansible en forma de archivos yml comunes, en lugar de describirlo en c\u00f3digo Python. <\/p>\n<p>Adem\u00e1s, en Ansible se pasan a trav\u00e9s de *extra_vars* el nombre del dispositivo de bloque, el estado del ticket y el callback_url, en el que est\u00e1 incrustado el issue key, que se utiliza para el callback en HTTP.<\/p>\n<p>Para cada ejecuci\u00f3n se genera un inventario temporal, que consiste en un solo host y un grupo que incluye este host, para que se apliquen group_vars.<\/p>\n<p>Aqu\u00ed hay un ejemplo de tarea en la que se implementa el callback HTTP.<\/p>\n<p>Los resultados de la ejecuci\u00f3n de los playbooks los obtenemos a trav\u00e9s de callback(-s). Hay dos tipos:<\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/docs.ansible.com\/ansible\/latest\/plugins\/callback.html\">Ansible callback plugin<\/a><\/noindex>, proporciona datos sobre los resultados de la ejecuci\u00f3n del playbook. Describe las tareas que se han iniciado, ejecutadas con \u00e9xito o fallidas. Este callback se llama al finalizar la ejecuci\u00f3n del playbook.<\/li>\n<li>Callback HTTP para obtener informaci\u00f3n durante la ejecuci\u00f3n del playbook. En la tarea de Ansible hacemos una solicitud POST\/GET hacia nuestra aplicaci\u00f3n.<\/li>\n<\/ul>\n<p>\nA trav\u00e9s de callbacks HTTP se pasan las variables que se definieron durante la ejecuci\u00f3n del playbook y que queremos guardar y utilizar en ejecuciones posteriores. Estos datos los escribimos en sqlite.<\/p>\n<p>Tambi\u00e9n a trav\u00e9s del callback HTTP dejamos comentarios y cambiamos el estado del ticket.<\/p>\n<p><b class=\"spoiler_title\">Callback HTTP<\/b><\/p>\n<pre><code class=\"plaintext\"># Make callback to Diskobot App\n# Variables:\n#    callback_post_body: # A dict with follow keys. All keys are optional\n#       msg: If exist it would be posted to Jira as comment\n#       data: If exist it would be saved in Incident.variables\n#       desire_state: Set desire_state for incident\n#       status: If exist Proceed issue to that status\n\n  - name: Callback to Diskobot app (jira comment\/status)\n    uri:\n      url: \"{{ callback_url }}\/{{ devname }}\"\n      user: \"{{ diskobot_user }}\"\n      password: \"{{ diskobot_pass }}\"\n      force_basic_auth: True\n      method: POST\n      body: \"{{ callback_post_body | to_json }}\"\n      body_format: json\n    delegate_to: 127.0.0.1\n<\/code><\/pre>\n<p>Al igual que muchas tareas similares, lo sacamos a un archivo com\u00fan y lo incluimos cuando es necesario, para no repetir constantemente en los playbooks. Aqu\u00ed aparece el callback_url, que contiene la clave del issue y el nombre del host. Cuando Ansible realiza esta solicitud POST, el bot entiende que ha llegado en el marco de tal incidente.<\/p>\n<p>Aqu\u00ed hay un ejemplo de un playbook en el que sacamos el disco de un dispositivo MD:<\/p>\n<pre><code class=\"plaintext\">  # Save mdadm configuration\n  - include: common\/callback.yml\n    vars:\n      callback_post_body:\n        status: 'Ready to change'\n        msg: \"Removed disk from mdraid {{ mdadm_remove_disk.msg | comment_jira }}\"\n        data:\n          mdadm_data: \"{{ mdadm_remove_disk.removed }}\"\n          parted_info: \"{{ parted_info | default() }}\"\n    when:\n      - mdadm_remove_disk | changed\n      - mdadm_remove_disk.removed\n<\/code><\/pre>\n<p>\nEsta tarea cambia el estado del ticket de Jira a \"Listo para cambiar\" y a\u00f1ade un comentario. Tambi\u00e9n, en la variable mdam_data se guarda la lista de dispositivos md de los cuales se ha eliminado el disco, y en parted_info \u2014 un volcado de la partici\u00f3n desde parted. <\/p>\n<p>Cuando el ingeniero inserte un nuevo disco, podremos utilizar estas variables para restaurar el volcado de las particiones, as\u00ed como registrar el disco en aquellos dispositivos md de los que fue eliminado.<\/p>\n<h3>Modo de verificaci\u00f3n de Ansible<\/h3>\n<p>\nActivar la automatizaci\u00f3n era aterrador. Por lo tanto, decidimos ejecutar todos los playbooks en modo <br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/docs.ansible.com\/ansible\/latest\/user_guide\/playbooks_checkmode.html\">de prueba<\/a><\/noindex>, en el que Ansible no realiza ninguna acci\u00f3n en los servidores, solo las emula. <\/p>\n<p>Este inicio se ejecuta a trav\u00e9s de un m\u00f3dulo de callback separado, y guardamos el resultado de la ejecuci\u00f3n del playbook en Jira como un comentario.<\/p>\n<p><img decoding=\"async\" alt=\"Automatizaci\u00f3n del reemplazo de discos con Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/b02d7f1dc428f2797ae8556cd496b115.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn primer lugar, esto permiti\u00f3 validar el funcionamiento del bot y los playbooks. En segundo lugar, aument\u00f3 la confianza de los administradores en el bot. <\/p>\n<p>Cuando pasamos la validaci\u00f3n y entendimos que se pod\u00eda ejecutar Ansible no solo en modo de prueba, creamos en Jira un bot\u00f3n \"Ejecutar Diskobot\" para lanzar el mismo playbook con las mismas variables en el mismo host, pero en modo normal. <\/p>\n<p>Adem\u00e1s, el bot\u00f3n se utiliza para reiniciar el playbook en caso de que falle.<\/p>\n<h3>Estructura de los Playbooks<\/h3>\n<p>\nYa mencion\u00e9 que, dependiendo del estado del ticket de Jira, el bot ejecuta diferentes playbooks.<\/p>\n<p>En primer lugar, es mucho m\u00e1s f\u00e1cil organizar la entrada. <br \/>\nEn segundo lugar, en algunos casos, es simplemente necesario. <\/p>\n<p>Por ejemplo, al reemplazar el disco del sistema, primero hay que ir al sistema de despliegue, crear una tarea, y despu\u00e9s de un despliegue correcto, el servidor estar\u00e1 disponible por ssh, y se podr\u00e1 implementar la aplicaci\u00f3n. Si hici\u00e9ramos todo esto en un solo playbook, Ansible no podr\u00eda ejecutarlo debido a la inaccesibilidad del host.<\/p>\n<p>Utilizamos roles de Ansible para cada grupo de servidores. Aqu\u00ed se puede ver c\u00f3mo est\u00e1n organizados los playbook(s) en uno de ellos. <\/p>\n<p><img decoding=\"async\" alt=\"Automatizaci\u00f3n del reemplazo de discos con Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/7a14035392b33f01d3182d5fff779321.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEs conveniente porque se puede ver de inmediato d\u00f3nde est\u00e1n ubicadas las tareas. En main.yml, que es la entrada para el rol de Ansible, podemos tener simplemente un include seg\u00fan el estado del ticket o tareas generales necesarias para todos, como la identificaci\u00f3n o la obtenci\u00f3n de un token.<\/p>\n<h4>Investigation.yml<\/h4>\n<p>\nSe ejecuta para tickets en estado de Investigaci\u00f3n y Abierto. Lo m\u00e1s importante para este playbook es el nombre del dispositivo de bloque. Esta informaci\u00f3n no siempre est\u00e1 disponible. <\/p>\n<p>Para obtenerla, analizamos el resumen de Jira, el \u00faltimo valor del trigger de Zabbix. Puede contener el nombre del dispositivo de bloque \u2014 si tenemos suerte. Tambi\u00e9n puede contener un punto de montaje; entonces, es necesario ir al servidor, analizar y calcular el disco necesario. Adem\u00e1s, el trigger puede transmitir la direcci\u00f3n SCSI o alguna otra informaci\u00f3n. Pero a veces no hay ninguna pista y hay que analizar.<\/p>\n<p>Una vez que tenemos el nombre del dispositivo de bloque, recopilamos informaci\u00f3n sobre el tipo y tama\u00f1o del disco para llenar los campos en Jira. Tambi\u00e9n recolectamos informaci\u00f3n sobre el vendedor, modelo, firmware, ID, SMART, y todo esto lo insertamos en el comentario del ticket de Jira. As\u00ed, el administrador y el ingeniero no necesitan buscar esta informaci\u00f3n. \ud83d\ude42<\/p>\n<p><img decoding=\"async\" alt=\"Automatizaci\u00f3n del reemplazo de discos con Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/259bf8712c013ee00d238f111b4280fb.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h4>prepare2change.yml<\/h4>\n<p>\nSacar el disco de la rotaci\u00f3n, prepar\u00e1ndose para el reemplazo. Es la etapa m\u00e1s dif\u00edcil y crucial. Aqu\u00ed es donde se puede detener la aplicaci\u00f3n cuando no se puede detener. O extraer el disco que no ten\u00eda suficientes r\u00e9plicas, afectando as\u00ed a los usuarios y perdiendo algunos datos. Aqu\u00ed tenemos la mayor cantidad de verificaciones y notificaciones en el chat.<\/p>\n<p>En el caso m\u00e1s simple, se trata de eliminar el disco del RAID HW\/MD. <\/p>\n<p>En situaciones m\u00e1s complejas (en nuestros sistemas de almacenamiento), cuando la redundancia se realiza a nivel de aplicaci\u00f3n, es necesario comunicarse con la aplicaci\u00f3n a trav\u00e9s de la API, informar sobre la desconexi\u00f3n del disco, desactivarlo y comenzar la recuperaci\u00f3n.<\/p>\n<p>Estamos migrando masivamente a <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/odnoklassniki\/blog\/346868\">la nube<\/a><\/noindex>, y si el servidor es en la nube, Diskobot se comunica con la API de la nube, indica que va a trabajar con este minion \u2014 el servidor donde se ejecutan los contenedores \u2014 y pide 'migrar todos los contenedores de este minion'. Y adem\u00e1s activa la iluminaci\u00f3n del disco para que el ingeniero vea de inmediato cu\u00e1l necesita ser extra\u00eddo.<\/p>\n<h4>changed.yml<\/h4>\n<p>\nDespu\u00e9s de reemplazar el disco, primero verificamos su disponibilidad. <\/p>\n<p>Los ingenieros no siempre instalan discos nuevos, por lo que a\u00f1adimos una verificaci\u00f3n de los valores SMART que nos satisfacen.<\/p>\n<p><b class=\"spoiler_title\">\u00bfQu\u00e9 atributos estamos observando?<\/b>Cuenta de Sectores Reasignados (5) &lt; 100<br \/>\nCuenta de Sectores Pendientes Actuales (107) == 0<\/p>\n<p>Si el disco no pasa la verificaci\u00f3n, se informa al ingeniero para su reemplazo. Si todo est\u00e1 bien, se apaga la luz indicadora, se marca y se introduce el disco en rotaci\u00f3n.<\/p>\n<h4>ready.yml<\/h4>\n<p>\nEl caso m\u00e1s sencillo: verificar la sincronizaci\u00f3n de RAID HW\/SW o la finalizaci\u00f3n de la sincronizaci\u00f3n de datos en la aplicaci\u00f3n.<\/p>\n<h3>API de aplicaciones<\/h3>\n<p>\nHe mencionado varias veces que el bot a menudo se conecta a la API de aplicaciones. Claro, no todas las aplicaciones ten\u00edan los m\u00e9todos necesarios, por lo que tuvimos que desarrollarlos. Aqu\u00ed est\u00e1n los m\u00e9todos m\u00e1s importantes que usamos:<\/p>\n<ul>\n<li>Estado. El estado del cl\u00faster o del disco para entender si se puede trabajar con \u00e9l;\n<\/li>\n<li>Iniciar\/detener. Activar\/desactivar disco;\n<\/li>\n<li>Migrar\/restaurar. Migraci\u00f3n y recuperaci\u00f3n de datos durante y despu\u00e9s del reemplazo.\n<\/li>\n<\/ul>\n<p><\/p>\n<h3>Experiencia adquirida sobre Ansible<\/h3>\n<p>\nMe encanta Ansible. Pero a menudo, cuando miro diferentes proyectos de c\u00f3digo abierto y veo c\u00f3mo la gente escribe playbooks, me asusta un poco. Enredos l\u00f3gicos complejos de when\/loop, falta de flexibilidad e idempotencia debido al uso frecuente de shell\/command.<\/p>\n<p>Decidimos simplificar todo lo posible, aprovechando la ventaja de Ansible: la modularidad. En el nivel m\u00e1s alto est\u00e1n los playbooks, que puede escribir cualquier administrador o desarrollador externo que sepa un poco de Ansible.<\/p>\n<pre><code class=\"plaintext\">- name: Parpadear disco\n  become: True\n  register: locate_action\n  disk_locate:\n      locate: '{{ locate }}'\n      devname: '{{ devname }}'\n      ids: '{{ locate_ids | default(pd_id) | default(omit) }}'\n<\/code><\/pre>\n<p>Si alguna l\u00f3gica es dif\u00edcil de implementar en los playbooks, la llevamos a un m\u00f3dulo o filtro de Ansible. Los scripts pueden escribirse tanto en Python como en cualquier otro lenguaje. <\/p>\n<p>Son f\u00e1ciles y r\u00e1pidos de escribir. Por ejemplo, el m\u00f3dulo para hacer parpadear el disco, cuyo ejemplo de uso se presenta arriba, consta de 265 l\u00edneas.<\/p>\n<p><img decoding=\"async\" alt=\"Automatizaci\u00f3n del reemplazo de discos con Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/08e0384bfad24f3ee61e0643ca087852.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn el nivel m\u00e1s bajo se encuentra la biblioteca. Para este proyecto, escribimos una aplicaci\u00f3n separada, una especie de abstracci\u00f3n sobre RAID de hardware y software, que realiza las solicitudes adecuadas. <\/p>\n<p><img decoding=\"async\" alt=\"Automatizaci\u00f3n del reemplazo de discos con Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/0edda3182026ce6279bd84c99613e3d6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLas mayores fortalezas de Ansible son la simplicidad y los playbooks claros. Creo que se debe aprovechar esto y no generar horribles archivos yaml y una gran cantidad de condiciones, c\u00f3digo shell y loops.<\/p>\n<p>Si deseas replicar nuestra experiencia con la API de Ansible, ten en cuenta dos cosas:<\/p>\n<ul>\n<li>No se puede pasar un tiempo de espera a Playbook_executor y, en general, a playbook. Hay un tiempo de espera en sesiones SSH, pero no hay un tiempo de espera para el playbook. Si intentamos desmontar un disco que ya no existe en el sistema, el playbook seguir\u00e1 ejecut\u00e1ndose indefinidamente, por lo que tuvimos que envolver su ejecuci\u00f3n en un wrapper separado y detenerlo por tiempo de espera.\n<\/li>\n<li>Ansible funciona sobre la base de procesos fork, por lo que su API no es segura para m\u00faltiples hilos. Ejecutamos todos nuestros playbooks en un solo hilo.\n<\/li>\n<\/ul>\n<p>\nComo resultado, logramos automatizar la sustituci\u00f3n de aproximadamente el 80% de los discos. En general, la velocidad de reemplazo se ha duplicado. Hoy en d\u00eda, el administrador solo observa el incidente y decide si debe cambiar el disco o no, y luego hace un solo clic.<\/p>\n<p>Pero ahora empezamos a enfrentarnos a otro problema: algunos de los nuevos administradores no saben c\u00f3mo cambiar discos. \ud83d\ude42<br \/>\n<br \/>Fuente: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/odnoklassniki\/blog\/452110\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442. \u042f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0432\u0435\u0434\u0443\u0449\u0438\u043c \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u043c \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440\u043e\u043c \u0432 \u041e\u041a \u0438 \u043e\u0442\u0432\u0435\u0447\u0430\u044e \u0437\u0430 \u0441\u0442\u0430\u0431\u0438\u043b\u044c\u043d\u0443\u044e \u0440\u0430\u0431\u043e\u0442\u0443 \u043f\u043e\u0440\u0442\u0430\u043b\u0430. \u0425\u043e\u0447\u0443 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043c\u044b \u0432\u044b\u0441\u0442\u0440\u043e\u0438\u043b\u0438 \u043f\u0440\u043e\u0446\u0435\u0441\u0441 \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u0439 \u0437\u0430\u043c\u0435\u043d\u044b \u0434\u0438\u0441\u043a\u043e\u0432, \u0430 \u0437\u0430\u0442\u0435\u043c, \u043a\u0430\u043a \u0438\u0441\u043a\u043b\u044e\u0447\u0438\u043b\u0438 \u0438\u0437 \u044d\u0442\u043e\u0433\u043e \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430 \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440\u0430 \u0438 \u0437\u0430\u043c\u0435\u043d\u0438\u043b\u0438 \u0435\u0433\u043e \u0431\u043e\u0442\u043e\u043c. \u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0441\u0432\u043e\u0435\u0433\u043e \u0440\u043e\u0434\u0430 \u0442\u0440\u0430\u043d\u0441\u043b\u0438\u0442\u0435\u0440\u0430\u0446\u0438\u0435\u0439 \u0432\u044b\u0441\u0442\u0443\u043f\u043b\u0435\u043d\u0438\u044f \u043d\u0430 HighLoad+ 2018 \u041f\u043e\u0441\u0442\u0440\u043e\u0435\u043d\u0438\u0435 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430 \u043f\u043e \u0437\u0430\u043c\u0435\u043d\u0435 \u0434\u0438\u0441\u043a\u043e\u0432 \u0421\u043d\u0430\u0447\u0430\u043b\u0430 \u043d\u0435\u043c\u043d\u043e\u0433\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26233,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34841","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=\"description\" content=\"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442.\" \/>\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\/avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible\" \/>\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\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0430\u0446\u0438\u044f \u0437\u0430\u043c\u0435\u043d\u044b \u0434\u0438\u0441\u043a\u043e\u0432 \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e Ansible | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible\" \/>\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=\"2019-10-31T19:00:43+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:00:43+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\udd47Automatizaci\u00f3n del reemplazo de discos con Ansible | ProHoster","description":"Hola a todos.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible","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\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0430\u0446\u0438\u044f \u0437\u0430\u043c\u0435\u043d\u044b \u0434\u0438\u0441\u043a\u043e\u0432 \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e Ansible | ProHoster","og:description":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible","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":"2019-10-31T19:00:43+00:00","article:modified_time":"2019-10-31T19:00:43+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34841","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":"2026-01-21 20:48:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:14:05","updated":"2026-01-21 20:48:19","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\/34841","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=34841"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/34841\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/26233"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=34841"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=34841"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=34841"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}