{"id":53098,"date":"2019-11-23T00:00:00","date_gmt":"2019-11-22T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/operatsiya-migratsiya-kak-proishodit-pereezd-v-oblako-dataline"},"modified":"2020-02-18T14:00:57","modified_gmt":"2020-02-18T11:00:57","slug":"operatsiya-migratsiya-kak-proishodit-pereezd-v-oblako-dataline","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/operatsiya-migratsiya-kak-proishodit-pereezd-v-oblako-dataline","title":{"rendered":"Operaci\u00f3n \u201cMigraci\u00f3n\u201d: c\u00f3mo se realiza la mudanza a la nube DataLine","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hace unos 7 a\u00f1os, los primeros proyectos se trasladaban a nuestra nube de manera sencilla y sin complicaciones. Las im\u00e1genes de las m\u00e1quinas virtuales se cargaban en un servidor FTP o se tra\u00edan en discos duros. Luego, a trav\u00e9s de un servidor de importaci\u00f3n especial, se sub\u00edan las m\u00e1quinas virtuales a la nube.<\/p>\n

Si para el cliente no es un problema apagar la virtualizaci\u00f3n durante uno o dos d\u00edas (o no hay otras opciones), se puede hacer de esa manera. Pero si el tiempo de inactividad debe ser como m\u00e1ximo de una hora, este m\u00e9todo no ser\u00eda adecuado. Hoy hablar\u00e9 sobre las herramientas que pueden ayudar a migrar a la nube con el m\u00ednimo tiempo de inactividad y sobre c\u00f3mo funciona el proceso de migraci\u00f3n con nosotros.<\/p>\n

\"Operaci\u00f3n
\n<\/a><\/noindex><\/p>\n

Migraci\u00f3n utilizando Veeam Backup and Replication<\/h3>\n

\nVeeam Backup and Replication es conocido por ser una herramienta para la creaci\u00f3n de copias de seguridad y r\u00e9plicas. Lo usamos para migrar entre nuestras plataformas y para transferir clientes de virtualizaci\u00f3n privada a nuestra nube. Las m\u00e1quinas virtuales del cliente se replican en nuestro vCenter, luego un ingeniero las agrega al vCloud Director. <\/p>\n

La replicaci\u00f3n inicial se lleva a cabo con la m\u00e1quina virtual encendida. En un momento acordado, se apaga la m\u00e1quina del lado del cliente. La replicaci\u00f3n se reinicia para trasladar los cambios que ocurrieron desde la primera replicaci\u00f3n. Despu\u00e9s de eso, la m\u00e1quina virtual se inicia en nuestra nube. <\/p>\n

\"Operaci\u00f3n
\n
\nGeneralmente, desde el momento en que la m\u00e1quina se apaga en la infraestructura del cliente hasta que se enciende en nuestra nube, pasa un tiempo no mayor de media hora, y m\u00e1s bien de 15 a 20 minutos. <\/p>\n

A su vez, en la instalaci\u00f3n del cliente queda la m\u00e1quina virtual original. Si algo sale mal, siempre se puede volver a encenderla. Para el cliente, este m\u00e9todo tambi\u00e9n es conveniente ya que no requiere la presencia de Veeam.<\/p>\n

Caso 1
\nEl cliente ten\u00eda su propia infraestructura virtual basada en VMware: 40 m\u00e1quinas virtuales con un volumen de 30 TB. El equipo en el que se hab\u00eda desplegado el cl\u00faster ya estaba desactualizado, y el cliente decidi\u00f3 no preocuparse por la compra de nuevo hardware y mudarse a la nube p\u00fablica. El requisito para el tiempo de inactividad de sistemas cr\u00edticos era de no m\u00e1s de una hora. Como herramienta, se eligi\u00f3 Veeam Replication. Tambi\u00e9n fue una ventaja que el proveedor de Internet del cliente estaba presente en nuestro centro de datos, lo que permiti\u00f3 organizar un buen canal. La migraci\u00f3n tom\u00f3 alrededor de un mes, y el tiempo de inactividad durante el cambio fue de hasta 30 minutos para un grupo de m\u00e1quinas virtuales.<\/i><\/p>\n

Migraci\u00f3n a trav\u00e9s de Veeam Cloud Connect<\/h3>\n

\nVeeam Cloud Connect es una herramienta que ayuda a configurar la replicaci\u00f3n de m\u00e1quinas virtuales y a ejecutar r\u00e9plicas en la nube del proveedor de servicios. Tras la actualizaci\u00f3n en 2019<\/a><\/noindex> el a\u00f1o, se agreg\u00f3 la capacidad de replicar m\u00e1quinas virtuales directamente en vCloud Director. La \u00fanica condici\u00f3n es que el cliente debe tener desplegado su propio Veeam Backup and Replication en versi\u00f3n 9 o superior. En resumen (la versi\u00f3n detallada aqu\u00ed<\/a><\/noindex>), el proceso se ve de la siguiente manera.<\/p>\n

En vCloud Director se crea una organizaci\u00f3n con los recursos y redes necesarios. En Veeam Cloud Connect creamos una cuenta, el cliente se conecta a ella desde su Veeam B&R, selecciona el proveedor DataLine y la organizaci\u00f3n, configura las tareas para la replicaci\u00f3n. Adem\u00e1s, durante esta migraci\u00f3n, el tiempo de inactividad ser\u00e1 de 15 a 20 minutos, y el cliente no depende del soporte t\u00e9cnico del proveedor, gestionando todo el proceso de manera aut\u00f3noma: configura las tareas de replicaci\u00f3n, la replicaci\u00f3n en s\u00ed misma, apaga las m\u00e1quinas y las reinicia en el nuevo sitio. <\/p>\n

\"Operaci\u00f3n
\n
\nCaso 2
\nLa infraestructura del cliente, desde donde se planeaba la migraci\u00f3n, estaba ubicada en Bielorrusia. Era necesario trasladar 90 VM con un volumen total de 27 TB, teniendo en cuenta que el canal de Internet era de 100 Mbit\/s. Si se hiciera una copia de seguridad y se subiera inmediatamente a nuestra nube, para algunas VM esto tomar\u00eda varios d\u00edas. Durante este tiempo, la VM generar\u00eda una gran delta, lo que podr\u00eda afectar negativamente el rendimiento de las m\u00e1quinas o, lo que es peor, podr\u00eda agotarse el espacio en el datastorage. El proceso fue el siguiente: primero, el cliente realiz\u00f3 una copia de seguridad completa localmente y traslad\u00f3 una copia a nuestra nube a trav\u00e9s de Veeam Cloud Connect. Luego, realiz\u00f3 y traslad\u00f3 un incremento a la nube. La m\u00e1quina virtual original continu\u00f3 funcionando. Despu\u00e9s de apagar la VM, el cliente hizo otro incremento y tambi\u00e9n lo traslad\u00f3 a la nube. De nuestra parte, desplegamos la m\u00e1quina virtual desde la copia de seguridad completa y luego aplicamos los dos incrementos. Este esquema permiti\u00f3 reducir el tiempo de inactividad a 2 horas al cambiar a nuestra plataforma. <\/i><\/p>\n

Migraci\u00f3n mediante VMware vCloud Availability<\/h3>\n

\nEn marzo de este a\u00f1o, VMware lanz\u00f3 vCloud Availability 3.0, que permite migrar m\u00e1quinas virtuales entre diferentes nubes (vCloud Director \u2013 vCloud Director) y desde los entornos de virtualizaci\u00f3n privados del cliente a la nube (vCenter \u2013 vCloud Director). La principal facilidad es la integraci\u00f3n con la interfaz de vCloud Director. Esto simplifica significativamente el proceso de gesti\u00f3n de replicaci\u00f3n y minimiza el tiempo de inactividad durante la conmutaci\u00f3n.<\/p>\n

Con esta herramienta, migramos a uno de nuestros clientes desde nuestra nube de Mosc\u00fa a nuestra nube en San Petersburgo. Era necesario trasladar 18 m\u00e1quinas virtuales con una capacidad total de 14 TB. Se cre\u00f3 una organizaci\u00f3n para el cliente en la nube de San Petersburgo y se organizaron las redes necesarias. Luego, desde la interfaz de vCloud Director, el cliente accedi\u00f3 a la configuraci\u00f3n de vCloud Availability, cre\u00f3 tareas de replicaci\u00f3n y se conmut\u00f3 a la plataforma de San Petersburgo en un momento conveniente para \u00e9l. El tiempo de inactividad durante la conmutaci\u00f3n fue de 12 minutos.<\/p>\n

\"Operaci\u00f3n
\nDiagrama de migraci\u00f3n entre las nubes de DataLine en San Petersburgo y Mosc\u00fa.<\/i><\/p>\n

En vCloud Availability hay un mecanismo para migrar VMs desde la plataforma del cliente a nuestra nube. Para esto, se despliega un appliance especial de vCloud Availability en el vCenter del cliente. Despu\u00e9s de una configuraci\u00f3n sencilla, se conecta a la nube y se configuran las tareas de migraci\u00f3n. El cliente tambi\u00e9n gestiona todo el proceso de forma independiente, y el tiempo de migraci\u00f3n se minimiza.<\/p>\n

\"Operaci\u00f3n
\nDiagrama de migraci\u00f3n de m\u00e1quinas virtuales desde una instalaci\u00f3n privada a la nube.<\/i><\/p>\n

VMware vCloud Availability tiene muchos otros escenarios de uso, pronto hablaremos de ellos en un art\u00edculo separado. <\/p>\n

Preparaci\u00f3n para la migraci\u00f3n <\/h3>\n

\nPara elegir la herramienta y comenzar la migraci\u00f3n, es necesario aclarar los siguientes puntos:<\/p>\n

De d\u00f3nde migramos. <\/b>Si est\u00e1 migrando desde una soluci\u00f3n privada, tiene total libertad en la elecci\u00f3n de herramientas. Si se est\u00e1 mudando de un proveedor, la situaci\u00f3n es m\u00e1s compleja. Lo m\u00e1s probable es que no se pueda vincular las infraestructuras de dos proveedores y simplemente arrastrar la VM debido a consideraciones de seguridad. A veces, el proveedor del que el cliente desea desvincularse comienza a poner obst\u00e1culos y retrasa el proceso. La migraci\u00f3n desde un proveedor se puede hacer de la manera antigua: exportando la VM a discos y utilizando FTP o migrando a nivel de la aplicaci\u00f3n. El nombre de este \u00faltimo es condicional y funciona aproximadamente as\u00ed.<\/p>\n

Caso 3
\nEra necesario migrar el sistema SAP del cliente de un proveedor europeo: 34 VM con un volumen de 54 TB. Se asignaron recursos en nuestra nube al cliente. Se estableci\u00f3 conectividad de red entre nosotros y la infraestructura del proveedor europeo. Los servidores de aplicaciones se desplegaron nuevamente, aplicando las configuraciones necesarias. Las grandes bases de datos se migraron mediante la carga de respaldos en nuestra nube. Luego, se configur\u00f3 la replicaci\u00f3n entre las bases de datos en nuestra y la plataforma original. En el momento acordado, cambiamos a las bases de datos en nuestra nube.<\/i><\/p>\n

Volumen de datos y ancho de banda de Internet.<\/b> Normalmente pedimos al cliente que proporcione una exportaci\u00f3n de los sistemas con los par\u00e1metros de memoria, CPU y discos. Evaluamos si el canal es suficiente para enviar directamente las r\u00e9plicas o los respaldos de las m\u00e1quinas virtuales. <\/p>\n

Downtime aceptable.<\/b> Para diferentes sistemas y, por lo tanto, m\u00e1quinas virtuales, puede variar dependiendo de su criticidad para el negocio. Generalmente, el cliente llega con requisitos predefinidos sobre el tiempo de inactividad durante la migraci\u00f3n, y con base en esto elegimos la herramienta adecuada y el plan de migraci\u00f3n. Intentamos programar el cambio final durante la noche o los fines de semana, para que incluso un peque\u00f1o per\u00edodo de inactividad no sea perceptible para los usuarios finales del cliente. <\/p>\n

A partir de estos datos, se puede elegir la herramienta y proceder con la migraci\u00f3n. Esto es lo que sucede a continuaci\u00f3n.<\/p>\n

    \n
  1. Configuraci\u00f3n de la conectividad de red. <\/b>Organizamos la conectividad de red entre nuestra nube y la infraestructura del cliente. A trav\u00e9s de esta red se copiar\u00e1n las m\u00e1quinas virtuales. Si se utiliza Veeam Backup and Replication, ser\u00e1 un canal dedicado, y menos frecuentemente, un canal VPN. Si se utiliza Veeam Cloud Connect, todo va a trav\u00e9s de Internet o el mismo canal dedicado.\n

    Luego, se configura la red para las VM en la nube. Las m\u00e1quinas normalmente se trasladan en grupos y no en un solo d\u00eda. Despu\u00e9s de que las VM se transfieran a nosotros y se inicien, deben interactuar con las m\u00e1quinas que a\u00fan permanecen en la plataforma original. <\/li>\n

  2. Calendario de migraci\u00f3n.<\/b> Cuando hay muchas m\u00e1quinas, es razonable dividirlas en grupos y transportarlas por lotes. Junto con el cliente, acordamos un plan en el que detallamos cu\u00e1ndo y qu\u00e9 m\u00e1quinas se trasladan y cu\u00e1ndo se realizar\u00e1 la replicaci\u00f3n final y el cambio a la nueva plataforma. <\/li>\n
  3. Migraci\u00f3n de prueba.<\/b> Migramos la m\u00e1quina virtual de prueba y verificamos que todo est\u00e9 configurado correctamente: conectividad de red entre las plataformas, accesibilidad de la m\u00e1quina virtual desde las m\u00e1quinas en la plataforma original, derechos de la cuenta y dem\u00e1s. Esta prueba ayuda a evitar contratiempos en la fase de migraci\u00f3n en producci\u00f3n.<\/li>\n<\/ol>\n

    \nEso es todo de mi parte. En los comentarios, no duden en hacer preguntas y compartir su experiencia de migraci\u00f3n.
    \n
    Fuente:     habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u041b\u0435\u0442 7 \u043d\u0430\u0437\u0430\u0434 \u0441\u0430\u043c\u044b\u0435 \u043f\u0435\u0440\u0432\u044b\u0435 \u043f\u0440\u043e\u0435\u043a\u0442\u044b \u043f\u0435\u0440\u0435\u0435\u0437\u0436\u0430\u043b\u0438 \u0432 \u043d\u0430\u0448\u0435 \u043e\u0431\u043b\u0430\u043a\u043e \u043f\u0440\u043e\u0441\u0442\u043e \u0438 \u043d\u0435\u0437\u0430\u0442\u0435\u0439\u043b\u0438\u0432\u043e. \u041e\u0431\u0440\u0430\u0437\u044b \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u0445 \u043c\u0430\u0448\u0438\u043d \u0437\u0430\u0433\u0440\u0443\u0436\u0430\u043b\u0438\u0441\u044c \u043d\u0430 FTP-\u0441\u0435\u0440\u0432\u0435\u0440, \u0438\u043b\u0438 \u0438\u0445 \u043f\u0440\u0438\u0432\u043e\u0437\u0438\u043b\u0438 \u043d\u0430 \u0436\u0435\u0441\u0442\u043a\u0438\u0445 \u0434\u0438\u0441\u043a\u0430\u0445. \u0417\u0430\u0442\u0435\u043c \u0447\u0435\u0440\u0435\u0437 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u044c\u043d\u044b\u0439 \u0438\u043c\u043f\u043e\u0440\u0442-\u0441\u0435\u0440\u0432\u0435\u0440 \u0412\u041c \u0437\u0430\u0433\u0440\u0443\u0436\u0430\u043b\u0438 \u0432 \u043e\u0431\u043b\u0430\u043a\u043e. \u0415\u0441\u043b\u0438 \u0434\u043b\u044f \u043a\u043b\u0438\u0435\u043d\u0442\u0430 \u043d\u0435 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0432\u044b\u043a\u043b\u044e\u0447\u0438\u0442\u044c \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u043a\u0443 \u043d\u0430 \u0441\u0443\u0442\u043a\u0438-\u0434\u0432\u043e\u0435 (\u0438\u043b\u0438 \u043d\u0435\u0442 \u0434\u0440\u0443\u0433\u0438\u0445 \u0432\u0430\u0440\u0438\u0430\u043d\u0442\u043e\u0432), \u0442\u043e \u043c\u043e\u0436\u043d\u043e \u0438 \u0442\u0430\u043a. \u041d\u043e \u0435\u0441\u043b\u0438 \u043f\u0440\u043e\u0441\u0442\u043e\u0439 \u0434\u043e\u043b\u0436\u0435\u043d \u0431\u044b\u0442\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-53098","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Operaci\u00f3n \u201cMigraci\u00f3n\u201d: c\u00f3mo se realiza el traslado a la nube de DataLine | ProHoster","description":"Hace unos 7 a\u00f1os, los primeros proyectos se trasladaban a nuestra nube de manera simple y sin complicaciones. Las im\u00e1genes de las m\u00e1quinas virtuales se cargaban en el servidor FTP o se transportaban en discos duros.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/operatsiya-migratsiya-kak-proishodit-pereezd-v-oblako-dataline","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\u041e\u043f\u0435\u0440\u0430\u0446\u0438\u044f \u201c\u041c\u0438\u0433\u0440\u0430\u0446\u0438\u044f\u201d: \u043a\u0430\u043a \u043f\u0440\u043e\u0438\u0441\u0445\u043e\u0434\u0438\u0442 \u043f\u0435\u0440\u0435\u0435\u0437\u0434 \u0432 \u043e\u0431\u043b\u0430\u043a\u043e DataLine | ProHoster","og:description":"\u041b\u0435\u0442 7 \u043d\u0430\u0437\u0430\u0434 \u0441\u0430\u043c\u044b\u0435 \u043f\u0435\u0440\u0432\u044b\u0435 \u043f\u0440\u043e\u0435\u043a\u0442\u044b \u043f\u0435\u0440\u0435\u0435\u0437\u0436\u0430\u043b\u0438 \u0432 \u043d\u0430\u0448\u0435 \u043e\u0431\u043b\u0430\u043a\u043e \u043f\u0440\u043e\u0441\u0442\u043e \u0438 \u043d\u0435\u0437\u0430\u0442\u0435\u0439\u043b\u0438\u0432\u043e. \u041e\u0431\u0440\u0430\u0437\u044b \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u0445 \u043c\u0430\u0448\u0438\u043d \u0437\u0430\u0433\u0440\u0443\u0436\u0430\u043b\u0438\u0441\u044c \u043d\u0430 FTP-\u0441\u0435\u0440\u0432\u0435\u0440, \u0438\u043b\u0438 \u0438\u0445 \u043f\u0440\u0438\u0432\u043e\u0437\u0438\u043b\u0438 \u043d\u0430 \u0436\u0435\u0441\u0442\u043a\u0438\u0445 \u0434\u0438\u0441\u043a\u0430\u0445.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/operatsiya-migratsiya-kak-proishodit-pereezd-v-oblako-dataline","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-11-22T21:00:00+00:00","article:modified_time":"2020-02-18T11:00:57+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"53098","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-24 06:04:31","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 14:29:47","updated":"2026-01-24 06:04:31","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\/53098","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=53098"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/53098\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=53098"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=53098"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=53098"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}