Wenn die Amazonen nur noch kriechen

nospam@example.com (Thomas Hochstein) — Thu, 21 Nov 2019 06:40:00 +0000

Grundsätzlich bin ich ja mit meinem Provider, der Deutschen Telekom, und meinem VDSL-Anschluss sehr zufrieden: bislang (überraschend) guter Kundenservice, wenn man ihn denn mal braucht, stabile Anbindung (vor dem letzten Disconnect am frühen Morgen war ich weit über einen Monat ununterbrochen verbunden), auch sonst keine Probleme.

Zwar las ich bereits vor (nunmehr bald fünf!) Jahren bei Daniel Weber über die Peering-Policy der Telekom, die man wohl zusammenfassen kann als “wir bauen überlastete Verbindungen gezielt nicht aus, es sei denn, die großen Inhaltsanbieter (Facebook, Youtube, große Hoster …) kommen uns finanziell oder anderweitig entgegen; dann schaffen wir für die eine Sonderlösung”. Wer da nicht mitspielen will, muss eben damit leben, dass die Telekom-Kunden (und das sind ja nun viele) den Eindruck haben, der Anbieter sei schlecht zu erreichen. Das ist fraglos nicht fair, und es ist auch für das Netz und im Grundsatz auch für die Telekom-Kunden nicht gut; bislang habe ich insoweit aber keine großen Auswirkungen gespürt.

Anfang November berichtete Daniel dann von der versuchten Umschaltung der Kunden eines aufgekauften niederländischen Anbieters auf das Netz der Telekom, unter Kündigung der bisherigen dezentralen Peering-Angebote. Und das ging nun offenbar kräftig in die Hose.

Ungefähr zur gleichen Zeit fielen mir sehr langsame Reaktionszeiten bei verschiedenen Webanbietern auf: zunächst bei XING, dem Business-Netzwerk, dessen Profilseiten sich - jedenfalls, was die Bilder betrifft - geradezu quälend langsam aufbauten; die Ladezeiten näherten sich teilweise dem Minutenbereich. Interessanterweise schien mir das Phänomen nur manchmal aufzutreten; bei genauerer Betrachtung vor allem am Wochenende, teilweise auch abends, also zu den Zeiten, wo mit intensiverer Netznutzung zu rechen ist. Danach ging es dann bei Keybase weiter: unter der Woche laufen die Webseiten ganz normal, ein Klick und die Seite öffnet sich. Am Wochenende kann man teilweise erst einmal einen Kaffee holen gehen; da kann es mal 10, mal 20, mal 30 Sekunden oder länger dauern, bis einzelne Seiten geladen werden. Wo XING hostet, sei mal dahingestellt, Keybase jedenfalls nutzt (wie sehr viele Anbieter) die Amazon-Cloud, also AWS, Amazon Web Services, und da sollte eigentlich ausreichend Leistung bereitstehen.

Nun kann man natürlich nie ausschließen, dass ein Unternehmen - zumal eines, das vermutlich bislang ohne größere Einnahmen arbeitet, von Venture-Kapital abgesehen - mit dem Ausbau seiner Kapazitäten eher zurückhaltend umgeht, aber vorletzte Woche wurde es dann völlig lächerlich. Ich hatte eine Lizenz für ein Programm erworben und dieses nun herunterzuladen; das sollte mit 250 MBit in der Anbindung eine Sache von Sekunden, vielleicht Minuten sein, jedenfalls - samt Installation - noch schnell vor dem Abendessen erledigt. Sollte man denken.

Download im Browser über VDSL.

Offenbar ein Irrtum. Rund anderthalb Stunden für 165 MB. Wie bitte?!

Auch der Download kommt von Amazon - und es war Wochenende. Offenbar ist das kein Problem eines einzelnen Anbieters, sondern ein Problem der Verbindung zu AWS insgesamt; nur, von welcher Seite aus? Von Amazon oder von der Telekom? Sollte Daniel mit seinen Bemerkungen zur Peering-Politik der Telekom recht haben? Nun, das lässt sich testen (und zugleich der Download deutlich beschleunigen); wozu betreibe ich einige Server? Also versuchen wir den Download eben von dort, aus dem Rechenzentrum eines größeren deutschen Serverhosters.

Derselbe Download vom Server aus.

2.54 MB/s ist jetzt auch kein Überschallknall, aber doch “etwas” flotter als 33 kB/s. So war der Download dann auch in etwas mehr als einer Minute erledigt, statt nach weit über einer Stunde. Und vom Server nach Hause dauerte es auch länger als eine Minute, aber nicht viel. Offenkundig liegt das Problem also nicht in der Anbindung von Seiten der Amazon Web Services (was mich auch überrascht hätte).

Womit ich jetzt wirklich fragen muss: Telekom, ist das echt euer Ernst?!

Backups in die Cloud (duply und S3)

nospam@example.com (Thomas Hochstein) — Tue, 29 Mar 2016 13:00:00 +0000

Eigentlich wollte ich schon vor gut drei Jahren, im Januar 2013, über dieses Thema schreiben, als ich die ersten Backup-Jobs dieser Art eingerichtet habe, aber irgendwie ist aus dem angefangenen Entwurf nie ein fertiger Blogeintrag geworden. - Nun denn, auf ein neues.

Nicht nur der heimische Rechner will regelmäßig gesichert werden; auch bei dedizierten Servern oder vServern ist ein regelmäßiges Backup vonnöten, um im Falle eines Falles nicht ohne (Code und) Daten dazustehen. Früher war es üblich, dass zu einem Server auch ein - meist per FTP zugänglicher - Backupplatz gehörte, der genügend Raum für ein Backup (auch über mehrere Generationen) bot. Mittlerweile müssen solche Angebote aber nicht selten kostenpflichtig hinzugebucht werden oder stehen gar nicht mehr zur Verfügung. Zwar ist es natürlich möglich, die Datensicherung auf einen anderen (eigenen oder fremden) Server durchzuführen, wobei sich die Maschine im heimischen Keller in der Regel wegen der geringen Upload-Bandbreiten nicht anbietet - schließlich will man nicht nur sichern, sondern notfalls auch wiederherstellen können. Eine Alternative ist aber Cloud-Speicher, bspw. Amazons S3 (Simple Storage Service). Die Kosten sind bei inkrementiellen Backups überschaubar: ein Gigabyte Speicherplatz kostet pro Monat ungefähr 3 Cent, dazu kommen noch geringen Kosten für Zugriffsoperationen in der Größenordnung von einem halben Cent pro 1.000 Zugriffe und für den ausgehenden Traffic - also vor allem für einen Restore - 9 Cent pro GB, jeweils zzgl. MWSt. Wöchentliche inkrementielle Backups mit monatlichen Vollbackups für vier Server kommen auf gut 10$.

Backup mit duply in einen AWS S3-“Bucket”

Für verschlüsselte und komprimierte Backups bieten sich duplicity und duply an; die grundsätzliche Einrichtung von duply habe ich bereits 2011 beschrieben. Zusätzlich benötigen wir für das Cloud-Backup noch dreierlei: einen S3-“Bucket”, in dem die Backups landen sollen, Zugangsdaten für diesen “Bucket”, und eine Anpassung der duply-Konfiguration.

Für die Nutzung der Amazon Web Services (AWS) ist eine Anmeldung dort erforderlich. Außerdem empfiehlt es sich sehr, nicht mit den Daten des Haupt-Accounts auf unseren S3-“Bucket” zuzugreifen, sondern mit einem extra dafür erzeugten Nutzeraccount, der dann auch nur auf diesen “Bucket” zugreifen kann. Dazu dient das Identity and Access Management (IAM).

AWS-Konfiguration

Fangen wir an mit der Anlage des S3-Speicherplatzes. Dazu genügt es, in der S3 Console mit Klick auf Create einen neuen “Bucket” anzulegen. Der vergebene Name muss AWS-weit eindeutig sein, es empfiehlt sich daher etwas in der Form accountname-backup-servername o.ä. Dabei muss dieser Name eine gültige Subdomain darstellen (vgl. die AWS-Dokumentation) und er sollte - um spätere Schwierigkeiten beim Zugriff zu vermeiden - keine Punkte enthalten. (Mit duplicity und den zugehörigen Libraries unter Debian Wheezy hatte ich keine Zugriffsprobleme auf Buckets, die Punkte im Namen haben, mit den Versionen in Debian Jessie jedoch sehr wohl. Better safe than sorry … ) Außerdem kann die geographische Region ausgewählt werden, in der der “Bucket” angelegt werden soll. Neben Irland ist hier nun auch Frankfurt als Standort auswählbar; für den Zugriff dort wird aber nur die Protokollversion 4 unterstützt, was wiederum zu Schwierigkeiten führen kann. Ich empfehle daher eu-west-1 (Irland) als Region.

Jetzt brauchen wir noch einen Benutzer, der auf den Bucket zugreifen kann. Ein solcher lässt sich in der IAM Console anlegen. Die dabei erzeugte Access-Key-ID und der zugehörige Secret Key müssen unbedingt heruntergeladen und sicher aufbewahrt werden.

Danach bekommt der neu erzeugte Benutzer noch eine Policy mit den nötigen Zugriffsrechten verpasst. Dazu wählen wir ihn in der Benutzerliste aus, wählen den Tab Permissions an und klicken unter Inline Policies auf Create User Policy. Diese Policy sollte dann wie folgt aussehen:

{
    "Statement": [
        {
            "Action": [
                "s3:ListAllMyBuckets"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Action": "s3:*",
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::accountname-backup-servername",
                "arn:aws:s3:::accountname-backup-servername/*"
            ]
        }
    ]
}

Statt accountname-backup-servername ist der Name des vorher neu angelegten S3-Buckets zu verwenden. Dieser Benutzer darf sich also eine Liste aller “Buckets” anzeigen lassen und auf den genannten “Bucket” und alle Dateien darin zugreifen.

duply-Konfiguration

Update: Die Beschreibung der Konfiguration gilt für Debian 8.0 Jessie und Debian 9.0 Stretch.

In der duply-Konfiguration (Datei conf) treffen wir jetzt noch folgende Einstellungen:

TARGET='s3://s3-eu-west-1.amazonaws.com/accountname-backup-servername'
TARGET_USER='AccessKeyID'
TARGET_PASS='SecretAccessKey'

Update: Ab Debian Stretch muss es statt TARGET_USER und TARGET_PASS wie folgt heißen:

export AWS_ACCESS_KEY_ID='AccessKeyID'
export AWS_SECRET_ACCESS_KEY='SecretAccessKey'

Für s3-eu-west-1 (Region Irland), accountname-backup-servername, AccessKeyID und SecretAccessKey sind jeweils die passenden Werte zu verwenden; AccessKeyID und SecretAccessKey wurden bei der Einrichtung des IAM-Benutzers erzeugt.

Außerdem müssen duplicity noch einige zusätzliche Parameter übergeben werden:

DUPL_PARAMS="$DUPL_PARAMS --s3-use-new-style --s3-european-buckets --s3-use-multiprocessing "

Update: Ab Debian Stretch benötigt auch gpg zusätzliche Parameter:

GPG_OPTS='--pinentry-mode loopback'

Jetzt kann der erste Backuplauf mit duply NAME backup gestartet werden. Nach dem Abschluss des Backup-Laufs finden sich im “Bucket” in der S3 Console die gesicherten Dateien.

Fertig!

Netz - Rettung - Recht (Artikel mit Tag aws)

Wenn die Amazonen nur noch kriechen

Backups in die Cloud (duply und S3)

Backup mit duply in einen AWS S3-“Bucket”

AWS-Konfiguration

duply-Konfiguration