{"id":34596,"date":"2019-10-31T21:59:16","date_gmt":"2019-10-31T18:59:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/zhivut-li-bazy-dannyh-v-kubernetes\/"},"modified":"2019-10-31T21:59:16","modified_gmt":"2019-10-31T18:59:16","slug":"zhivut-li-bazy-dannyh-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/zhivut-li-bazy-dannyh-v-kubernetes","title":{"rendered":"Leben Datenbanken in Kubernetes?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Leben
\n
\nHistorisch gesehen hat sich die IT-Branche irgendwie in zwei Lager aufgeteilt: die, die \"daf\u00fcr\" sind, und die, die \"dagegen\" sind. Dabei kann das Streitthema v\u00f6llig willk\u00fcrlich sein. Welches Betriebssystem ist besser: Win oder Linux? Auf dem Smartphone Android oder iOS? Alles in der Cloud speichern oder auf kalte RAID-Speicher hochladen und die Festplatten im Safe aufbewahren? Haben PHP-Entwickler das Recht, sich Programmierer zu nennen? Diese Streitigkeiten sind manchmal rein existenzieller Natur und basieren auf nichts anderem als sportlichem Interesse.<\/p>\n

So kam es, dass mit dem Aufkommen von Containern und all dieser uns vertrauten Docker-K\u00fcche und dem hypothetischen k8s auch die Streitigkeiten \"daf\u00fcr\" und \"dagegen\" \u00fcber die Nutzung neuer M\u00f6glichkeiten in verschiedenen Bereich des Backends begannen. (Vorweg sei gesagt, dass im Folgenden Kubernetes als Orchestrator angegeben wird, wobei die Wahl dieses speziellen Werkzeugs f\u00fcr das Argument keine wesentliche Bedeutung hat. Man kann stattdessen jedes andere einsetzen, das man als am bequemsten und vertrautesten empfindet.)<\/p>\n

Und, so scheint es, w\u00e4re das ein einfacher Streit zwischen zwei Seiten einer Medaille. Ebenso sinnlos und gnadenlos wie das ewige Duell Win vs Linux, in dem vern\u00fcnftige Menschen irgendwo dazwischen existieren. Doch im Fall der Containerisierung ist nicht alles so einfach. Normalerweise gibt es in solchen Streitereien keine rechte Seite, aber im Fall von \"Container zur Speicherung von Datenbanken verwenden\" oder \"nicht verwenden\" wird alles auf den Kopf gestellt. Denn in gewissem Sinne haben sowohl die Bef\u00fcrworter als auch die Gegner eines solchen Ansatzes recht.
\n<\/a><\/noindex><\/p>\n

Die Helle Seite<\/h4>\n

\nDie Argumentation der Hellen Seite l\u00e4sst sich mit einem Satz zusammenfassen: \"Hallo, 2k19 steht vor der T\u00fcr!\" Das klingt zwar nach Populismus, aber wenn man die Situation genauer betrachtet, gibt es auch Vorteile. Die werden wir jetzt analysieren.<\/p>\n

Angenommen, Sie haben ein gro\u00dfes Webprojekt. Es k\u00f6nnte urspr\u00fcnglich auf einem mikroservicebasierten Ansatz aufgebaut worden sein oder sich zu einem bestimmten Zeitpunkt evolution\u00e4r dorthin entwickelt haben \u2013 das ist eigentlich nicht so wichtig. Sie haben Ihr Projekt in einzelne Mikrodienste aufgeteilt, die Orchestrierung, Lastverteilung und Skalierung eingerichtet. Und jetzt genie\u00dfen Sie mit reinem Gewissen einen Mojito in einer H\u00e4ngematte w\u00e4hrend der Habr-Effekte, anstatt die abgest\u00fcrzten Server neu zu starten. Aber in allen Handlungen muss man konsequent sein. Sehr oft wird nur die Anwendung selbst containerisiert \u2013 der Code. Und was haben wir noch au\u00dfer dem Code?<\/p>\n

Richtig, die Daten. Das Herzst\u00fcck jedes Projekts sind seine Daten: das kann sowohl eine typische Datenbank wie MySQL, Postgre, MongoDB als auch Speicher f\u00fcr Suchanfragen (ElasticSearch), key-value Speicher f\u00fcr das Caching \u2013 zum Beispiel redis, usw. sein. Heute werden wir nicht \u00fcber fehlerhafte Backend-Implementierungen sprechen, bei denen die Datenbank aufgrund schlecht geschriebener Abfragen zusammenbricht, sondern dar\u00fcber, wie man die Ausfallsicherheit dieser Datenbank unter Clientlast gew\u00e4hrleistet. Denn wenn wir unsere Anwendung containerisieren und ihr erlauben, sich ungehindert zu skalieren, um beliebig viele eingehende Anfragen zu verarbeiten, erh\u00f6ht sich zwangsl\u00e4ufig auch die Last auf der Datenbank.<\/p>\n

Tats\u00e4chlich wird der Zugang zur Datenbank und der Server, auf dem sie l\u00e4uft, zu einem Engpass in unserem sch\u00f6nen containerisierten Backend. Dabei ist das Hauptmotiv der Container-Virtualisierung \u2013 die Beweglichkeit und Flexibilit\u00e4t der Struktur, die es erm\u00f6glicht, die Spitzenlastverteilung \u00fcber unsere gesamte verf\u00fcgbare Infrastruktur so effizient wie m\u00f6glich zu organisieren. Das bedeutet, dass wir, wenn wir nicht alle vorhandenen Systemelemente containerisieren und im Cluster ausrollen, einen sehr schwerwiegenden Fehler machen.<\/p>\n

Es ist viel logischer, nicht nur die Anwendung selbst zu clustern, sondern auch die Dienste, die f\u00fcr die Datenspeicherung verantwortlich sind. Bei der Clusterbildung und dem Deployment von unabh\u00e4ngig arbeitenden und untereinander Last verteilen Web-Servern in k8s l\u00f6sen wir bereits das Problem der Datensynchronisation \u2013 insbesondere der Kommentare zu Beitr\u00e4gen, wenn wir als Beispiel ein Medium oder eine Blogplattform anf\u00fchren. In jedem Fall haben wir ein internes, wenn auch virtuelles, Datenbankdarstellung als ExternalService. Das Problem ist, dass die eigentliche Datenbank noch nicht geclustert ist \u2013 die im Cluster ausgef\u00fchrten Web-Server holen sich Informationen \u00fcber \u00c4nderungen aus unserer statischen Produktionsdatenbank, die separat l\u00e4uft.<\/p>\n

F\u00fchlen Sie den Hinterhalt? Wir verwenden k8s oder Swarm, um die Last zu verteilen und den Ausfall des Hauptsystems zu vermeiden, Webserver.<\/a>, aber wir tun dies nicht f\u00fcr die Datenbank. Aber wenn die Datenbank abst\u00fcrzt, macht das in unserer geclusterten Infrastruktur keinen Sinn \u2013 was nutzt uns eine leere Webseite, die einen Fehler beim Datenbankzugriff zur\u00fcckgibt?<\/p>\n

Genau deshalb m\u00fcssen nicht nur die Web-Server geclustert werden, wie es normalerweise der Fall ist, sondern auch die Datenbankinfrastruktur. Nur so k\u00f6nnen wir eine vollst\u00e4ndig funktionsf\u00e4hige Struktur im gleichen Atemzug aufbauen, die jedoch unabh\u00e4ngig voneinander arbeitet. Selbst wenn die H\u00e4lfte unseres Backends unter der Last \u201ezusammenbricht\u201c \u2013 der Rest \u00fcberlebt, und das System zur Datensynchronisation innerhalb des Clusters sowie die M\u00f6glichkeit der unbegrenzten Skalierung und des Deployments neuer Cluster helfen uns, schnell die ben\u00f6tigte Kapazit\u00e4t zu erreichen \u2013 sofern die Racks im Rechenzentrum vorhanden sind.<\/p>\n

Dar\u00fcber hinaus erm\u00f6glicht das verteilte Datenbankmodell in Clustern, diese Datenbank dorthin zu bringen, wo sie ben\u00f6tigt wird; wenn wir \u00fcber einen globalen Dienst sprechen, ist es ziemlich unlogisch, einen Web-Cluster irgendwo in der N\u00e4he von San Francisco zu betreiben und gleichzeitig die Pakete f\u00fcr den Zugriff auf die Datenbank nach und aus dem Moskauer Gebiet zu schicken.<\/p>\n

Au\u00dferdem erm\u00f6glicht die Containerisierung der Datenbank, alle Elemente des Systems auf derselben Abstraktionsebene zu konstruieren. Dies wiederum macht es m\u00f6glich, dieses System direkt aus dem Code zu steuern, von den Entwicklern, ohne aktive Einbeziehung von Admins. Die Entwickler dachten, dass eine separate DBMS f\u00fcr ein neues Teilprojekt erforderlich ist \u2013 kein Problem! Sie schrieben eine yaml-Datei, luden sie in den Cluster hoch, und das war's.<\/p>\n

Und nat\u00fcrlich wird dadurch die interne Nutzung erheblich vereinfacht. Sagen Sie, wie oft haben Sie die Augen zusammengekniffen, als ein neues Teammitglied seine H\u00e4nde in die Produktionsdatenbank gesteckt hat? Die, die Sie im Grunde genommen haben, die gerade jetzt l\u00e4uft? Nat\u00fcrlich sind wir hier alle erwachsene Menschen, und irgendwo haben wir ein frisches Backup, und noch weiter \u2014 hinter dem Regal mit Omas Gurken und alten Skiern \u2014 ein weiteres Backup, vielleicht sogar im kalten Speicher, weil Ihr B\u00fcro schon einmal gebrannt hat. Aber trotzdem, jedes Einf\u00fchren eines neuen Teammitglieds, das Zugang zur Produktionsinfrastruktur und nat\u00fcrlich zur Produktionsdatenbank hat \u2014 das ist ein Eimer Valium f\u00fcr alle Beteiligten. Wer wei\u00df, vielleicht ist der Neue ungeschickt? Erschreckend, stimmen Sie zu.<\/p>\n

Die Containerisierung und im Grunde genommen die verteilte physische Topologie der Datenbank Ihres Projekts helfen, solche Valium-Momente zu vermeiden. Vertrauen Sie dem Neuen nicht? Gut! Wir richten ihm einen eigenen Cluster f\u00fcr die Arbeit ein und trennen ihn von den anderen Datenbank-Clustern \u2014 Synchronisation nur per manuellem Push und synchronem Umlegen von zwei Schl\u00fcsseln (einer f\u00fcr den Teamleiter, der andere f\u00fcr den Administrator). Und alle sind gl\u00fccklich.<\/p>\n

Jetzt ist es an der Zeit, sich in Gegner der DB-Clusterisierung zu verwandeln.<\/p>\n

Die dunkle Seite<\/h4>\n

\nWenn man dar\u00fcber nachdenkt, warum man die Datenbank nicht containerisieren sollte und sie in einer zentralen Einrichtung weiterlaufen lassen sollte, Server<\/a>, wollen wir nicht in die Rhetorik der Orthodoxen und solche Aussagen abgleiten wie \u201eDie Alten betrieben die DB auf Hardware, und wir werden es auch!\u201c Stattdessen sollten wir versuchen, eine Situation zu erfinden, in der die Containerisierung tats\u00e4chlich sp\u00fcrbare Vorteile bringen w\u00fcrde.<\/p>\n

Stimmen Sie zu, dass Projekte, die wirklich eine Datenbank im Container ben\u00f6tigen, an einer Hand eines nicht so tollen Fr\u00e4sers abz\u00e4hlbar sind. In den meisten F\u00e4llen ist selbst die Nutzung von k8s oder Docker Swarm \u00fcbertrieben \u2014 sehr oft greifen die Leute auf diese Werkzeuge zur\u00fcck, aufgrund des allgemeinen Hypes um Technologien und der Anweisung der 'H\u00f6heren', alles in Clouds und Container zu packen. Nun, weil es gerade modern ist und alle es so machen.<\/p>\n

In mindestens der H\u00e4lfte der F\u00e4lle ist die Verwendung von Kubernetes oder einfach Docker im Projekt \u00fcbertrieben. Die Frage ist, dass nicht alle Teams oder Outsourcing-Unternehmen, die angeheuert wurden, um die Infrastruktur des Kunden zu betreuen, sich dessen bewusst sind. Schlimmer ist, wenn Container aufgezwungen werden, weil sie dem Kunden eine bestimmte Anzahl an M\u00fcnzen kosten.<\/p>\n

Es gibt die Meinung, dass Docker\/Kubernetes-Clubs einfach die Kunden unterdr\u00fccken, die diese Infrastrukturfragen outsourcen. Um mit Clustern zu arbeiten, braucht man Ingenieure, die dazu in der Lage sind und die Architektur der implementierten L\u00f6sung verstehen. Wir haben bereits unseren Fall mit der Publikation Republic beschrieben - dort haben wir das Team des Kunden geschult, im Umfeld von Kubernetes zu arbeiten, und alle waren zufrieden. Das war fair. Oft halten \u00bbImplementierer\u00ab von k8s die Infrastruktur des Kunden als Geisel - denn jetzt verstehen nur sie, wie alles funktioniert, und auf der Kundenseite gibt es keine Fachleute.<\/p>\n

Stellen Sie sich nun vor, dass wir nicht nur den Webserver-Teil an das Outsourcing abgeben, sondern auch die Wartung der Datenbank. Wir haben gesagt, die Datenbank ist das Herz, und der Verlust des Herzens ist fatal f\u00fcr jeden lebenden Organismus. Kurz gesagt, die Aussichten sind nicht die besten. Statt des gehypten Kubernetes w\u00e4re es f\u00fcr viele Projekte besser, einfach nicht geizig bei einem anst\u00e4ndigen Tarif bei AWS zu sein, der alle Lastprobleme ihrer Website\/ihres Projekts l\u00f6sen w\u00fcrde. Aber AWS ist schon nicht mehr in, und Prahlerei ist teuer - leider auch in der IT-Welt.<\/p>\n

Okay. Vielleicht braucht das Projekt wirklich eine Clusterbildung, aber wenn es bei stateless Anwendungen klar ist, wie dann eine angemessene Netzwerkverbindung f\u00fcr eine clusterisierte Datenbank organisiert werden kann?<\/p>\n

Wenn wir von einer nahtlosen Ingenieurl\u00f6sung sprechen, die den \u00dcbergang zu k8s darstellt, ist unser gr\u00f6\u00dftes Problem die Datenreplikation in einer clusterf\u00e4higen Datenbank. Einige DBMS gehen anfangs relativ tolerant mit der Verteilung von Daten zwischen ihren einzelnen Instanzen um. Viele andere sind jedoch weniger aufgeschlossen. Und h\u00e4ufig wird das Hauptargument bei der Auswahl eines DBMS f\u00fcr unser Projekt nicht unbedingt die F\u00e4higkeit zur Replikation mit minimalen Ressourcen- und Ingenieurausgaben sein. Besonders wenn das Projekt urspr\u00fcnglich nicht als mikroskopisches Dienstsystem geplant war, sondern sich einfach in diese Richtung entwickelt hat. <\/p>\n

Wir denken, dass man \u00fcber die Geschwindigkeit von Netzlaufwerken nicht extra sprechen muss \u2013 sie sind langsam. Das hei\u00dft, im Falle eines Falls haben wir keine wirkliche M\u00f6glichkeit, eine DBMS-Instanz irgendwo wiederherzustellen, wo es beispielsweise mehr Rechenleistung oder freien Arbeitsspeicher gibt. Sehr schnell sto\u00dfen wir an die Grenzen der Leistung eines virtualisierten Datenspeichersystems. Entsprechend muss das DBMS an seiner eigenen pers\u00f6nlichen Maschinenkonfiguration befestigt werden, die sich in unmittelbarer N\u00e4he befindet. Alternativ muss man irgendwie eine ausreichend schnelle Datensynchronisierung zu den vorgesehenen Reserven sicherstellen. <\/p>\n

Im Fortlauf der Diskussion \u00fcber virtuelle Dateisysteme: Docker Volumes sind bedauerlicherweise nicht ohne Probleme. Im Allgemeinen m\u00f6chten wir bei der langfristigen zuverl\u00e4ssigen Speicherung von Daten m\u00f6glichst einfache technische Systeme verwenden. Die Einf\u00fchrung einer neuen Abstraktionsebene vom Container-Dateisystem zum Dateisystem des \u00fcbergeordneten Hosts ist bereits ein Risiko an sich. Doch wenn es im Betrieb des Containerisierungs-Systems auch noch zu Schwierigkeiten mit der Daten\u00fcbertragung zwischen diesen Schichten kommt, dann wird es wirklich problematisch. Derzeit scheinen die meisten bekannten Probleme, die der fortschrittlichen Menschheit bekannt sind, weitgehend beseitigt. Aber wie Sie wissen, je komplexer der Mechanismus, desto einfacher bricht er.<\/p>\n

Angesichts all dieser \"Abenteuer\" ist es viel vorteilhafter und einfacher, die Datenbank an einem Ort zu behalten. Selbst wenn Sie eine Containerisierung der Anwendung ben\u00f6tigen, sollte sie f\u00fcr sich selbst laufen und \u00fcber einen Verteilungsgateway gleichzeitig auf eine Datenbank zugreifen, die nur einmal und an einem Ort gelesen und geschrieben wird. Dieser Ansatz reduziert die Wahrscheinlichkeit von Fehlern und Desynchronisationen auf ein Minimum.<\/p>\n

Worauf wollen wir hinaus? Auf die Tatsache, dass die Containerisierung von Datenbanken dann sinnvoll ist, wenn es einen echten Bedarf daf\u00fcr gibt. Man kann eine Datenbank eines Full-Apps nicht einfach nehmen und sie so betreiben, als h\u00e4tte man zwei Dutzend Mikrodienste \u2013 so funktioniert das nicht. Das muss klar verstanden werden.<\/p>\n

Statt einer Ausgabe<\/h4>\n

\nWenn Sie auf eine klare Aussage warten, ob man eine Datenbank virtualisieren sollte oder nicht, m\u00fcssen wir Sie entt\u00e4uschen: die wird es hier nicht geben. Denn bei der Erstellung jeder Infrastruktur muss man sich nicht von Mode und Fortschritt leiten lassen, sondern in erster Linie von gesundem Menschenverstand.<\/p>\n

Es gibt Projekte, in denen die Prinzipien und Werkzeuge von Kubernetes perfekt funktionieren, und in solchen Projekten herrscht zumindest im Backend-Bereich Frieden. Aber es gibt Projekte, die keine Containerisierung ben\u00f6tigen, sondern eine normale Serverinfrastruktur, weil sie grunds\u00e4tzlich nicht in der Lage sind, auf ein mikroskopisches Cluster-Modell umzuskalieren, da sie sonst zusammenbrechen.
\n
Quelle: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041a\u0430\u043a-\u0442\u043e \u0442\u0430\u043a \u0438\u0441\u0442\u043e\u0440\u0438\u0447\u0435\u0441\u043a\u0438 \u0441\u043b\u043e\u0436\u0438\u043b\u043e\u0441\u044c, \u0447\u0442\u043e IT-\u0438\u043d\u0434\u0443\u0441\u0442\u0440\u0438\u044f \u043f\u043e \u043b\u044e\u0431\u043e\u043c\u0443 \u043f\u043e\u0432\u043e\u0434\u0443 \u0440\u0430\u0437\u0431\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u043d\u0430 \u0434\u0432\u0430 \u0443\u0441\u043b\u043e\u0432\u043d\u044b\u0445 \u043b\u0430\u0433\u0435\u0440\u044f: \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u00ab\u0437\u0430\u00bb \u0438 \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u00ab\u043f\u0440\u043e\u0442\u0438\u0432\u00bb. \u041f\u0440\u0438\u0447\u0435\u043c \u043f\u0440\u0435\u0434\u043c\u0435\u0442 \u0441\u043f\u043e\u0440\u043e\u0432 \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c \u0430\u0431\u0441\u043e\u043b\u044e\u0442\u043d\u043e \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u043b\u044c\u043d\u044b\u043c. \u041a\u0430\u043a\u0430\u044f \u041e\u0421 \u043b\u0443\u0447\u0448\u0435: Win \u0438\u043b\u0438 Linux? \u041d\u0430 \u0441\u043c\u0430\u0440\u0442\u0444\u043e\u043d\u0435 Android \u0438\u043b\u0438 iOS? \u0425\u0440\u0430\u043d\u0438\u0442\u044c \u0432\u0441\u0435 \u0432 \u043e\u0431\u043b\u0430\u043a\u0430\u0445 \u0438\u043b\u0438 \u0437\u0430\u043b\u0438\u0432\u0430\u0442\u044c \u043d\u0430 \u0445\u043e\u043b\u043e\u0434\u043d\u044b\u0435 RAID-\u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u0438 \u043a\u043b\u0430\u0441\u0442\u044c \u0432\u0438\u043d\u0442\u044b \u0432 \u0441\u0435\u0439\u0444? \u0418\u043c\u0435\u044e\u0442 \u043b\u0438 PHP-\u0448\u043d\u0438\u043a\u0438 \u043f\u0440\u0430\u0432\u043e […]<\/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-34596","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\udd47Leben Datenbanken in Kubernetes? | ProHoster","description":"Es ist historisch so entstanden, dass die IT-Branche ein.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/zhivut-li-bazy-dannyh-v-kubernetes","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\u0416\u0438\u0432\u0443\u0442 \u043b\u0438 \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 \u0432 Kubernetes? | ProHoster","og:description":"\u041a\u0430\u043a-\u0442\u043e \u0442\u0430\u043a \u0438\u0441\u0442\u043e\u0440\u0438\u0447\u0435\u0441\u043a\u0438 \u0441\u043b\u043e\u0436\u0438\u043b\u043e\u0441\u044c, \u0447\u0442\u043e IT-\u0438\u043d\u0434\u0443\u0441\u0442\u0440\u0438\u044f \u043f\u043e.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/zhivut-li-bazy-dannyh-v-kubernetes","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-31T18:59:16+00:00","article:modified_time":"2019-10-31T18:59:16+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34596","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-02-09 21:46:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:18:36","updated":"2026-02-09 21:46:19","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\/34596","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=34596"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/34596\/revisions"}],"predecessor-version":[{"id":159764,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/34596\/revisions\/159764"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=34596"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=34596"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=34596"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}