{"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\/de\/blog\/administrirovanie\/operatsiya-migratsiya-kak-proishodit-pereezd-v-oblako-dataline","title":{"rendered":"Operation \u201eMigration\u201c: So erfolgt der Umzug in die Cloud von DataLine","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Vor etwa 7 Jahren zogen die ersten Projekte einfach und unkompliziert in unsere Cloud um. Abbildungen virtueller Maschinen wurden auf einen FTP-Server hochgeladen oder auf Festplatten transportiert. Dann wurden die VMs \u00fcber einen speziellen Import-Server in die Cloud geladen.<\/p>\n

Wenn es f\u00fcr den Kunden kein Problem ist, die virtuelle Maschine f\u00fcr ein oder zwei Tage abzuschalten (oder wenn es keine anderen Optionen gibt), kann man das so machen. Doch wenn die Ausfallzeit maximal eine Stunde betragen darf, ist dieses Vorgehen nicht geeignet. Heute erl\u00e4utere ich, welche Werkzeuge helfen, mit minimaler Ausfallzeit in die Cloud zu migrieren und wie der Migrationsprozess bei uns funktioniert.<\/p>\n

\"Operation
\n<\/a><\/noindex><\/p>\n

Migration mit Veeam Backup and Replication<\/h3>\n

\nVeeam Backup and Replication ist als Werkzeug zur Erstellung von Backups und Replikaten bekannt. Wir verwenden es f\u00fcr die Migration zwischen unseren Plattformen und f\u00fcr den Umzug von Kunden von privater Virtualisierung in unsere Cloud. Die virtuellen Maschinen der Kunden werden auf unser vCenter repliziert, danach f\u00fcgt der Ingenieur sie dem vCloud Director hinzu. <\/p>\n

Die erste Replikation erfolgt auf der eingeschalteten virtuellen Maschine. Zu einem vereinbarten Zeitpunkt wird die Maschine beim Kunden abgeschaltet. Die Replikation wird ein weiteres Mal gestartet, um die \u00c4nderungen zu \u00fcbertragen, die seit der ersten Replikation aufgetreten sind. Danach wird die virtuelle Maschine bereits in unserer Cloud gestartet. <\/p>\n

\"Operation
\n
\nIn der Regel vergehen vom Zeitpunkt der Abschaltung der Maschine in der Infrastruktur des Kunden bis zur Einschaltung in unserer Cloud nicht mehr als eine halbe Stunde, eher 15\u201320 Minuten. <\/p>\n

Dabei bleibt die urspr\u00fcngliche virtuelle Maschine beim Kunden vor Ort. Falls etwas schiefgeht, kann man sie immer wieder aktivieren. F\u00fcr den Kunden hat dieses Verfahren den Vorteil, dass er kein Veeam ben\u00f6tigt.<\/p>\n

Anwendungsfall 1
\nDer Kunde hatte seine eigene virtuelle Infrastruktur auf Basis von VMware \u2013 40 VMs mit einem Volumen von 30 TB. Die Hardware, auf der der Cluster eingerichtet war, war bereits veraltet, und der Kunde beschloss, sich nicht mit dem Kauf neuer Hardware zu besch\u00e4ftigen und in die \u00f6ffentliche Cloud umzuziehen. Die Anforderung an die Ausfallzeit kritischer Systeme lag bei maximal einer Stunde. Als Werkzeug wurde Veeam Replication gew\u00e4hlt. Positiv war auch, dass der Internetanbieter des Kunden in unserem Rechenzentrum pr\u00e4sent war, was einen guten Kanal erm\u00f6glichte. Die Migration dauerte etwa einen Monat, die Ausfallzeit beim Wechsel betrug bis zu 30 Minuten f\u00fcr eine Gruppe virtueller Maschinen.<\/i><\/p>\n

Migration mit Veeam Cloud Connect<\/h3>\n

\nVeeam Cloud Connect \u2013 ein Werkzeug, das hilft, die Replikation von virtuellen Maschinen einzurichten und Replikate in der Cloud des Dienstanbieters zu starten. Nach dem Update im 2019<\/a><\/noindex> Jahr wurde die M\u00f6glichkeit eingef\u00fchrt, virtuelle Maschinen direkt in den vCloud Director zu replizieren. Die einzige Voraussetzung ist, dass auf der Kundenseite eine eigene Veeam Backup and Replication-Version nicht \u00e4lter als 9 bereitgestellt wird. Kurz gesagt (die detaillierte Version hier<\/a><\/noindex>), sieht der gesamte Prozess wie folgt aus.<\/p>\n

Im vCloud Director wird eine Organisation mit den notwendigen Ressourcen und Netzwerken erstellt. In Veeam Cloud Connect richten wir ein Konto ein, das der Kunde \u00fcber sein Veeam B&R verbindet, w\u00e4hlt den Anbieter DataLine und die Organisation aus und konfiguriert Aufgaben f\u00fcr die Replikation. Neben der Tatsache, dass die Ausfallzeit w\u00e4hrend dieser Migration 15\u201320 Minuten betragen wird, ist der Kunde nicht auf den Support des Anbieters angewiesen und verwaltet den gesamten Prozess selbst: er erstellt Aufgaben zur Replikation, f\u00fchrt die eigentliche Replikation durch, schaltet Maschinen aus und startet sie an neuer Stelle. <\/p>\n

\"Operation
\n
\nFall 2
\nDie Infrastruktur des Kunden, von wo die Migration geplant wurde, befand sich in Wei\u00dfrussland. Es galt, 90 VMs mit einem Gesamtvolumen von 27 TB zu \u00fcbertragen, w\u00e4hrend die Internetverbindung 100 Mbit\/s betrug. Wenn ein Backup gemacht und sofort in unsere Cloud hochgeladen wird, w\u00fcrde das bei einigen VMs mehrere Tage in Anspruch nehmen. In dieser Zeit w\u00fcrde eine gro\u00dfe Delta auf den VMs entstehen, was sich negativ auf die Leistung der Maschinen oder, noch schlimmer, auf den Speicherplatz im Datastore auswirken k\u00f6nnte. Wir haben wie folgt vorgegangen: Zuerst hat der Kunde ein lokales vollst\u00e4ndiges Backup gemacht und eine Kopie davon \u00fcber Veeam Cloud Connect in unsere Cloud \u00fcbertragen. Danach hat er ein inkrementelles Backup gemacht und in die Cloud \u00fcbertragen. Die urspr\u00fcngliche virtuelle Maschine arbeitete weiter. Nach dem Ausschalten der VM hat der Kunde ein weiteres inkrementelles Backup gemacht und ebenfalls in die Cloud \u00fcbertragen. Auf unserer Seite haben wir die virtuelle Maschine aus dem vollst\u00e4ndigen Backup bereitgestellt und dann zwei inkrementelle Backups darauf aufgespielt. Dieses Vorgehen erm\u00f6glichte es letztendlich, die Ausfallzeit beim Wechsel auf unsere Plattform auf 2 Stunden zu minimieren. <\/i><\/p>\n

Migration mit VMware vCloud Availability<\/h3>\n

\nIm M\u00e4rz dieses Jahres hat VMware vCloud Availability 3.0 ver\u00f6ffentlicht, das es erm\u00f6glicht, virtuelle Maschinen zwischen verschiedenen Clouds (vCloud Director \u2013 vCloud Director) und von privaten Virtualisierungsumgebungen der Kunden in die Cloud (vCenter \u2013 vCloud Director) zu migrieren. Der Hauptvorteil ist die Integration mit der vCloud Director-Oberfl\u00e4che. Dies vereinfacht den Prozess der Replikationsverwaltung erheblich und minimiert die Ausfallzeiten beim Wechsel.<\/p>\n

Mit diesem Tool haben wir einen unserer Kunden aus unserer Moskauer Cloud in unsere Cloud in St. Petersburg migriert. Es mussten 18 virtuelle Maschinen mit einer Gesamtkapazit\u00e4t von 14 TB \u00fcbertragen werden. F\u00fcr den Kunden wurde in der St. Petersburger Cloud eine Organisation erstellt und die erforderlichen Netzwerke eingerichtet. Anschlie\u00dfend wechselte der Kunde \u00fcber die vCloud Director-Oberfl\u00e4che zu den Einstellungen von vCloud Availability, erstellte Replikationsauftr\u00e4ge und wechselte zu einem f\u00fcr ihn passenden Zeitpunkt zur St. Petersburger Instanz. Die Ausfallzeit beim Wechsel betrug 12 Minuten.<\/p>\n

\"Operation
\nDas Schema der Migration zwischen den Clouds DataLine in St. Petersburg und Moskau.<\/i><\/p>\n

vCloud Availability hat einen Mechanismus zur Migration von VM vom Standort des Kunden in unsere Cloud. Daf\u00fcr wird im vCenter des Kunden eine spezielle vCloud Availability Appliance bereitgestellt. Nach einer einfachen Konfiguration erfolgt die Verbindung zur Cloud und die Migration wird eingerichtet. Der Kunde verwaltet zudem den gesamten Prozess selbst, wodurch die Migrationszeit auf ein Minimum reduziert wird.<\/p>\n

\"Operation
\nDas Schema der Migration von virtuellen Maschinen aus einer privaten Installation in die Cloud.<\/i><\/p>\n

VMware vCloud Availability hat viele weitere Anwendungsszenarien, \u00fcber die wir bald in einem separaten Artikel berichten werden. <\/p>\n

Vorbereitung zur Migration <\/h3>\n

\nUm ein Werkzeug auszuw\u00e4hlen und mit der Migration zu beginnen, m\u00fcssen die folgenden Punkte gekl\u00e4rt werden:<\/p>\n

Woher migrieren wir? <\/b>Wenn Sie von einer privaten L\u00f6sung migrieren, haben Sie v\u00f6llige Freiheit bei der Auswahl der Werkzeuge. Wenn Sie von einem Anbieter wechseln, wird es komplizierter. H\u00f6chstwahrscheinlich wird es aufgrund von Sicherheits\u00fcberlegungen nicht m\u00f6glich sein, die Infrastrukturen beider Anbieter zu verbinden und die VM einfach zu verschieben. Manchmal beginnt der Anbieter, von dem sich der Kunde trennen m\u00f6chte, sogar zu schikanieren und verz\u00f6gert den Prozess. Man kann auf alte Weise von einem Anbieter wechseln: durch das Exportieren von VMs auf Festplatten und FTP oder durch eine migrationsbasierte Anwendung. Letzteres wird als eine bedingte Bezeichnung verwendet und sieht folgenderma\u00dfen aus.<\/p>\n

Fall 3
\nEs war notwendig, das SAP-System des Kunden von einem europ\u00e4ischen Anbieter zu migrieren: 34 VMs mit einem Volumen von 54 TB. Dem Kunden wurden Ressourcen in unserer Cloud zugewiesen. Zwischen uns und der Infrastruktur des europ\u00e4ischen Anbieters wurde eine Netzwerkverbindung hergestellt. Die Anwendungsserver wurden neu bereitgestellt, mit den erforderlichen Konfigurationen. Gro\u00dfe Datenbanken wurden durch das Laden von Backups in unsere Cloud migriert. Danach wurde die Replikation zwischen den Datenbanken auf unseren und den urspr\u00fcnglichen Standorten eingerichtet. Zum vereinbarten Zeitpunkt haben wir auf die Datenbanken in unserer Cloud umgeschaltet.<\/i><\/p>\n

Datenvolumen und Internetkanal.<\/b> Wir bitten den Kunden normalerweise, einen Export der Systeme mit den Parametern RAM, CPU, Festplatten bereitzustellen. Wir bewerten, ob der Kanal ausreicht, um Replikate oder Backups der virtuellen Maschinen direkt zu senden. <\/p>\n

Akzeptable Ausfallzeit.<\/b> F\u00fcr verschiedene Systeme und dementsprechend virtuelle Maschinen kann diese je nach Kritikalit\u00e4t f\u00fcr das Gesch\u00e4ft variieren. Normalerweise kommt der Kunde mit vorbereiteten Anforderungen an die Ausfallzeit w\u00e4hrend der Migration, und darauf basierend w\u00e4hlen wir das geeignete Werkzeug und den Migrationsplan aus. Wir versuchen, den endg\u00fcltigen Wechsel auf die Nacht oder das Wochenende zu planen, damit selbst eine geringe Ausfallzeit von den Endbenutzern des Kunden nicht bemerkt wird. <\/p>\n

Auf Grundlage dieser Daten kann das Werkzeug gew\u00e4hlt werden und die Migration kann beginnen. So geht es weiter.<\/p>\n

    \n
  1. Einrichtung der Netzwerkverbindung. <\/b>Wir organisieren die Netzwerkverbindung zwischen unserer Cloud und der Infrastruktur des Kunden. \u00dcber dieses Netzwerk werden die virtuellen Maschinen kopiert. Wenn Veeam Backup and Replication verwendet wird, dann \u00fcber einen dedizierten Kanal, seltener \u2013 \u00fcber einen VPN-Kanal. Wenn Veeam Cloud Connect verwendet wird, dann l\u00e4uft alles \u00fcber das Internet oder denselben dedizierten Kanal.\n

    Dann wird das Netzwerk f\u00fcr die VMs in der Cloud konfiguriert. Die Maschinen werden normalerweise in Gruppen verschoben und nicht an einem Tag. Nachdem die VMs zu uns transferiert und gestartet wurden, m\u00fcssen sie mit Maschinen interagieren, die weiterhin am urspr\u00fcnglichen Standort bleiben. <\/li>\n

  2. Migrationszeitplan.<\/b> Wenn es viele Maschinen gibt, ist es sinnvoll, sie in Gruppen aufzuteilen und in Chargen zu transportieren. Gemeinsam mit dem Kunden stimmen wir einen Plan ab, in dem festgelegt ist, wann und welche Maschinen umziehen und wann die endg\u00fcltige Replikation und der Wechsel auf den neuen Standort erfolgen. <\/li>\n
  3. Testmigration.<\/b> Wir migrieren die Test-VM und \u00fcberpr\u00fcfen, ob alles richtig konfiguriert ist: Netzwerkverbindung zwischen den Standorten, Erreichbarkeit der VM von Maschinen am urspr\u00fcnglichen Standort, Berechtigungen des Benutzerkontos usw. Ein solcher Test hilft, Verz\u00f6gerungen w\u00e4hrend der eigentlichen Migration zu vermeiden.<\/li>\n<\/ol>\n

    \nDas war's von meiner Seite. Stellen Sie Fragen in den Kommentaren und berichten Sie von Ihren Migrationserfahrungen.
    \n
    Quelle:     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\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\udd47Operation \u201eMigration\u201c: Wie der Umzug in die Cloud DataLine | ProHoster erfolgt.","description":"Vor etwa 7 Jahren wurden die ersten Projekte ganz einfach und unkompliziert in unsere Cloud migriert. Die Bilder der virtuellen Maschinen wurden auf einen FTP-Server hochgeladen oder auf Festplatten mitgebracht.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/operatsiya-migratsiya-kak-proishodit-pereezd-v-oblako-dataline","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","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\/de\/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\/de\/wp-json\/wp\/v2\/posts\/53098","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=53098"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/53098\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=53098"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=53098"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=53098"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}