Computer

0

Ich habe mich gerade beim übertragen von Daten mittels rsync im lokalen Netzwerk gewundert, dass die Übertragungsrate lediglich 20MB/s betrug und dabei die CPU der Flaschenhals war. Stellt sich heraus: SSHs Komprimierung ist schuld. Mit

rsync -e "ssh -o Compression=no" -av quelle ziel

sind es nun über 100MB/s und nur deshalb nicht mehr, weil Gigabit-Ethernet und die Festplatten jetzt der Flaschenhals sind. Diesen Unterschied müsste SSHs Komprimierung erst mal wett machen, was in diesem Fall sowieso vollkommen illusorisch ist, da die Daten bereits gut komprimiert sind. 😉

0

Neulich stieß ich auf eine Reihe englischsprachiger Essays, die sich mit den Veränderungen der Arbeitswelt seit Verbreitung von Computern und Internet beschäftigen. Unter dem Titel “Breaking Smart” beschreibt Venkatesh Rao, in einer ersten Staffel von Essays, was für Möglichkeiten die immer weiter fortschreitende Technologisierung mit sich bringt und welche Herausforderungen sie birgt. Da dies mit Abstand die besten Essays sind, die ich seit langem gelesen habe, möchte ich die Möglichkeit nicht missen hier darauf hinzuweisen.

0

Wie man diesem Blog entnehmen kann, bin ich schon länger Kunde bei 1&1. Bisher habe ich IPv6 über einen Tunnel bei Sixxs angebunden. Heute fragte ich mich wie inzwischen der Stand von nativem IPv6 bei 1&1 ist und musste feststellen, dass das in vielen Fällen schon direkt verfügbar ist, ohne das wie in Fällen anderer Anbieter ein neuer Vertrag notwendig ist.

  • Für Kunden mit VDSL-Produkt ist IPv6-Dualstack standardmäßig freigeschaltet.
  • Für einen Teil unserer ADSL-Kunden können wir IPv6-Dualstack als Vorabtest freischalten.

Quelle (leider nur mit Account): https://forum.1und1.de/index.php?page=Thread&postID=155432#post155432

Nachdem ich das gesehen hatte, habe ich direkt versucht natives IPv6 zu aktivieren und bekam sofort von 1&1 ein /56er Netz zugewiesen. Nun also kein Umweg über einen Sixxs PoP mehr.

0

tl;dr: C4 instances have a simpler design because they don’t have to support hard drives which makes them more reliable and cheaper for AWS.

C4 instances

At last years re:Invent AWS announced a new generation of compute-optimized EC2 instances: the C4 instance family. Back then they provided some technical details about these instances including the information that they are powered by a custom “Intel Xeon E5-2666 v3” processor built for AWS only, but the information regarding pricing or an availability date were still missing. Earlier this week these instances became available and pricing details and some remaining information were published as well.

Most press coverage about these new instance family focused on the custom built CPU, but the longer I think about it the more I think that this is just the tip of the iceberg.

Block storage at AWS

AWS is providing two different kinds of block storage: So called ephemeral storage, which is storage directly connected to the host system an instance is running on and EBS (Elastic Block Storage) volumes, which are network attached disks.
Ephemeral volumes have been available for most instances, only their smallest instance families (T1 and T2) don’t offer them. Depending on the instance you choose you’ll get a different amount of ephemeral storage which can be either HDD or SDD backed. The great thing about it: It’s free, because it’s a part of the price you already pay for an instance whether or not you use this storage. But there is as usual a caveat: Once you stop an instance the data stored on these volumes is gone, because there is no host system anymore which could hold the data.
EBS volumes are the means of choice if you want reliable block storage. In the past there have been performance bottlenecks with them, but since the introduction of IOPS EBS volumes, gp2 volumes and some improvements they are going to implement, that shouldn’t be an issue anymore.

One thing that went unnoticed with the C4 instances is, that these are the first instances (beside the small T1 and T2 instance) which don’t provide ephemeral storage at all!

I believe that’s a shift in AWS philosphy to decrease their costs and to ease their server architecture.

Custom hardware

We all know that companies like Google or AWS build their own hardware. Facebook goes a different way with it’s Open Compute project, but they all try to achieve the same goal: They want to have hardware perfectly matching their needs without including features they don’t need to drive costs down and increase reliability.

AWS started builing it’s own custom network equipment five years ago and they have several other specialized components as well, like big storage racks and of course the EC2 instances. But these instances always came with hard disks included to enable ephemeral storage. With the introduction of the C4 instances AWS seems to be confident enough that EBS volumes also fit the needs of customers which have been using ephemeral volumes before, so they omitted these ephemeral storage options, which allows them to omit hard drives completely from these instances. That removes on major pain point of such servers: Failing drives. That’s a big plus for reliability.

Power

AWS has published technical details about their custom “Intel Xeon E5-2666 v3” processor, but one interesting detail is missing: The TDP (Thermal Design Power), the maximum amount of power the CPU uses during normal operation. I wouldn’t be surprised if Intel managed to decrease that by a few watts for AWS, maybe by disabling features AWS will never use. But if AWS doesn’t even need hard drives they also don’t need SATA ports and only a limited number of PCIe-lanes for the network cards which would allow them to use a stripped down platform controller hub, which I believe Intel developed for them as well. So AWS uses a custom processor and might also use a custom platform controller hub, which both might save them a tiny fraction of needed power. Even if it’s a tiny fraction at the scale of AWS that’s a lot of saved money, which is important to drive the costs down to stay competitive.

Conclusion

The biggest news about the C4 instances isn’t the custom built processor, but the removal of the ability to use ephemeral volumes with them. With not providing such volumes AWS eleminated the need to add hard drives to these instances which removes a major point of failure of such servers and also drives down costs by making the design simpler and by maybe saving some watts of power. It’s interesting to see such developments and I’m pretty sure they’ll be enabling AWS to continue cutting prices in future as they did in the past.

1

Glücklicherweise habe ich seit etlichen Jahren ausgesprochen wenig mit Microsoft Windows zu tun. Sobald ich trotzdem mal mit Windows zu tun habe, tue ich zuallererst das, was man als braver Nutzer tut: Ich lasse es nach Sicherheitsupdates suchen. Für mich ist dabei immer wieder überraschend, dass Windows nach einer frischen Installation selbst nach mehrfachem Suchen und Installieren von Updates immer noch neue Updates findet, die es vorher nicht gefunden hat. Es Nutzern einfach zu machen ihre Rechner auf dem neusten Stand zu halten sieht anders aus.

0

Seit neuneinhalb Jahren nutze ich Debian und war immer ausgesprochen zufrieden damit. Als technisch versierterer Benutzer kann man ja dank testing und unstable ausreichend frische Softwareversionen nutzen. Der neueste Schrei ist nun der Ersatz von SysVinit durch systemd als Init-System. Da es bei meinem Setup noch kleinere Haken mit systemd gibt und mir systemd nach wie vor etwas ungeheuer ist, hatte ich vor so lange wie möglich bei SysVinit zu bleiben.

Die letzten Wochen mehrten sich dann aber mehrere Probleme:

  • Mein Notebook zeigte nach dem starten kein Bild mehr an, wenn beim starten der Splash von Plymouth aktiv war.
  • Auf sämtlichen Rechnern wird das tun-Modul für openvpn nicht mehr automatisch geladen, sondern muss per Hand geladen werden.
  • Suspend-to-RAM und Suspend-to-Disk waren im “Verlassen”-Bildschirm von KDE nicht mehr zu finden und das schließen des Notebookdeckels legte ihn auch nicht mehr schlafen.

Insbesondere der letzte Punkt nervte mich und ich machte mich auf die Suche nach der Ursache. Die fand ich auch recht schnell in Form eines Debian Bugreports: #752413 kde-workspace-bin: upower-1.0 transition. Spannend dabei die Aussage im letzten Kommentar:

It does mean as a consequence, that kde will depend on systemd/logind
for suspend/hibernate support.

Kurz entschlossen habe ich mein Notebook mal mit systemd neu gestartet und siehe da: Alle oben genannten Probleme waren mit einem Mal verschwunden. Das ärgert mich, denn es zeigt, dass SysVinit in Zukunft wohl kaum mehr vernünftig als Init-System für Desktoprechner verwendet werden können wird, wenn sogar jetzt schon ohne systemd Probleme auftreten, die mit ihm nicht auftreten.

0

Die Bezeichnung “Cloud” ist schon seit einer ganzen Weile ein Hype-Begriff und wurde von mir lange belächelt. Denn was unterscheidet schon “die Cloud” von dem, was schon immer das Internet selbst definiert?

Seit gut einem halben Jahr habe ich nun beruflich recht intensiv mit ebendieser Cloud zu tun, um genau zu sein mit Amazon Web Services (AWS).
Grundsätzlich stehe ich solchen großen Unternehmen wie Amazon erstmal skeptisch gegenüber, denn je größer ein Unternehmen desto wahrscheinlicher ist eine marktbeherrschende Stellung und die Ausnutzung dieser. Auch Amazon hat bereits mit seinem Online-Shop gezeigt wie gut sie in der Lage sind eine marktbeherrschende Stellung zu übernehmen.

Auch der Bereich Cloud-Computing ist bei Amazon inzwischen so groß, dass sie in diesem Bereich der größte Anbieter sind und er in Zukunft voraussichtlich ähnlich hohe Gewinne abwerfen wird wie ihr Online-Shop. Doch wodurch kommt das? Beim Online-Shop sind die wichtigsten Kriterien für den Erfolg meiner Meinung nach niedrige Preise und guter Service. Zumindest mit niedrigen Preisen kann AWS auf den ersten Blick nicht punkten.

Während man bei üblichen Hostern im niedrigen Preissegment in Deutschland problemlos Server mit Quadcore Prozessor, 16GB RAM und mehreren Terabyte an Plattenplatz für 50 Euro im Monat bekommt, zahlt man bei AWS in der billigsten Region (und zwar us-east-1 und us-west-2, beide in den USA) mindestens 300 Dollar für ähnliche Hardware. Bei Mehrausgaben von 500% muss also entweder ein relevanter Mehrwert vorhanden sein oder die Angebote von Amazon sind maßlos überteuert.

Die Erfahrungen der letzten Monate haben mir gezeigt, dass die Preise durchaus berechtigt sind und was “die Cloud” von herkömmlichen Webhostern unterscheidet.

  1. Amazon bietet nicht einfach wie andere Webhoster reine Hardware, sondern eine komplette Infrastruktur mit unterschiedlichsten Dienstleistungen und dazugehörigen Programmierschnittstellen (APIs) für diverse Sprachen an. So ist unglaublich viel Funktionalität um deren Bereitstellung man sich sonst selbst kümmern müsste bereits vorhanden und lässt sich neben einem Webinterface komplett über APIs nutzen und somit einfach in eigene Anwendungen einbinden.
  2. Hardwarenahe Probleme gehören der Vergangenheit an. Darum kümmert sich Amazon und da alles in irgendeiner Form virtualisiert läuft, bekommt man als Anwender davon auch nur in Ausnahmefällen etwas mit.
  3. Die Dokumenation der einzelnen Dienste ist umfangreich und verständlich und als größerer Kunde bekommt man unglaublich gute Betreuung und ausgezeichneten Support.
  4. Amazon ruht sich nicht auf seiner Marktstellung aus, sondern veröffentlicht fast im Tagesrythmus neue Verbesserungen ihrer Cloud-Plattform.
  5. Eigene Dienste lassen sich ohne großen Aufwand in lokal gruppierten, aber räumlich getrennten Rechenzentren (Availability Zones) oder auch weltweit verteilt über fünf Kontinente (Regions) betreiben.

Dazu kommt, dass die Preise aus dem oben genannten Beispiel bei intensiverer Nutzung je nach Anwendungsfall drastisch sinken, wenn man Reserved Instances oder Spot Instances nutzt.

Mir macht es, aufgrund der oben genannten Gründe, unglaublich viel Spaß mit AWS zu arbeiten und für mich ist inzwischen gut nachvollziehbar, warum Amazon im Bereich Cloud-Computing diese überragende Marktstellung hat: So schade das für gesunden Wettbewerb ist, aber es gibt einfach keinen Anbieter, der auch nur ansatzweise die gleichen Dienste bieten kann und wenn ich mir das Tempo an Innovationen bei Amazon anschaue, dann wird das auch noch lange so bleiben.

0

Die Debatte um die Deutsche Telekom, die sich in neuen DSL-Flatrate-Verträgen nun vorbehält nach dem überschreiten eines bestimmten Übertragungsvolumens die Verbindung zu drosseln, ist ja inzwischen nun schon ziemlich breit durchgekaut worden. Als Option wird es wohl möglich sein, gegen Aufpreis wieder eine echte Flatrate zu bekommen.
Ich frage mich allerdings, warum sich die Telekom überhaupt diesen medialen Stress gemacht hat? Sie hätte doch auch einfach die neuen Verträge nicht mehr Flatrate nennen und stattdessen entsprechend teurere Verträge mit der Bezeichnung Flatrate einführen können. Dann hätten sie PR-technisch sogar noch entgegengesetzt argumentieren können, dass bei ihren Nicht-Flatrate-Verträgen nach erreichen des Limits ja “nur” gedrosselt wird, statt gleich komplett abzuschalten.

0

Google hat heute eine Webseite zum schon länger in Entwicklung befindlichen “Project Glass” veröffentlicht. Glass ist platt gesagt eine intelligente Brille mit Kamera und Display, die es erlaubt im alltäglichen Leben ins eigene Sichtfeld zusätzliche Informationen eingeblendet zu bekommen und das eigene Sichtfeld zu filmen.
Auf der Webseite ist unter anderem auch das im Folgenden eingebettete Video zu finden.

Beim anschauen des Videos drängt sich mir förmlich auf, dass Google Glass, sobald es für den Massenmarkt für einen bezahlbaren Preis verfügbar ist (und dafür wird Google sorgen), das Produkt sein wird, nach dem Apple so krampfhaft sucht: The Next Big Thing.

0

Some time ago I had the requirement to limit the number of requests per IP to a CouchDB-instance. I couldn’t find an option for CouchDB to achieve that, but as communication with CouchDB is based on HTTP-requests I thought that it should be possible to use nginx as reverse proxy with rate-limiting capabilities for CouchDB. The CouchDB-wiki lists some basic steps how to use nginx as reverse proxy, but rate limiting isn’t mentioned there.

Beside the actual rate limiting I noticed that nginx won’t work, because it doesn’t support chunked request-bodies out of the box, which CouchDB seems to rely onto. But to the rescue there is a nginx module called ngx_chunkin, which adds chunkin support to nginx. To get that module in Debian you need to install nginx-extras from the repository (available since squeeze-backports). The configuration of that module is straight forward as described on the wiki page. All you have to do is to put the following code snippet into the server-context of your nginx configuration:

        chunkin on;

        error_page 411 = @my_411_error;
        location @my_411_error {
                chunkin_resume;
        }

Having solved that issue, doing the actual rate limiting was the next step. Therefore nginx ships the module ngx_http_limit_req_module. All I had to do was to configure a zone for the limited requests in the http-context of the configuration:

limit_req_zone $binary_remote_addr zone=couchdb_write:10m rate=10r/s;

and the logic what to rate limit (writing requests in my case) into the server-context:

        location / {
                # POST, PUT, DELETE ... requests will get rate limiting
                if ($request_method !~* GET) {
                        rewrite ^(.*)$ /throttled$1 last;
                }

                proxy_pass       http://127.0.0.1:5985;
                proxy_buffering  off;
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        location /throttled {
                internal;
                limit_req        zone=couchdb_write burst=10000;
                rewrite /throttled(.*) $1 break;
                proxy_pass       http://127.0.0.1:5985;
                proxy_buffering  off;
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

So if you put together the chunkin support and the rate limiting, you’ll get the following piece of configuration for a server which does rate limiting of writing CouchDB-requests using nginx:

limit_req_zone $binary_remote_addr zone=couchdb_write:10m rate=10r/s;

server {
        listen 5984;

        chunkin on;

        error_page 411 = @my_411_error;
        location @my_411_error {
                chunkin_resume;
        }

        location / {
                # POST, PUT, DELETE ... requests will get rate limiting
                if ($request_method !~* GET) {
                        rewrite ^(.*)$ /throttled$1 last;
                }

                proxy_pass       http://127.0.0.1:5985;
                proxy_buffering  off;
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        location /throttled {
                internal;
                limit_req        zone=couchdb_write burst=10000;
                rewrite /throttled(.*) $1 break;
                proxy_pass       http://127.0.0.1:5985;
                proxy_buffering  off;
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
}

I really enjoyed figuring that out, because it was a lot of fun to be able to use a great tool (nginx) to extend another great tool (CouchDB), because they’re using the same protocol (HTTP).