OVH Community, your new community space.

RPS News


Peter
03.07.08, 11:23
ACL auf NFS

Guten Tag,

wir haben Limitierungen auf der Ebene der NFS Server hinzugefügt, um die Überlastungen der letzten beiden Tage in Zukunft zu vermeiden. Dies kann die Graphen von collectd weniger brauchbar machen, aber das Verhalten des Servers verbessert sich dadurch.

Ursprünglich kommt das Problem daher, dass collectd seine Daten in rrd Dateien speichert. Und diese werden auf dem NFS gespeichert. Und leider funktioniert rrd auf NFS nicht sehr gut zusammen.

So kann man dann einen konstant eingehenden Datenstrom von 10 bis 20 Mbit/s auf dem Netzwerk beobachten wenn man collectd auf seinem Server betreibt. Der Linux Server liest immer wieder die rrd Dateien aus, anstatt die Kopie die er im Cache hat zu verwenden.

Wir arbeiten noch an diesem Problem, aber die ACL sind eine erste Antwort darauf.

Mit freundlichen Grüssen,

Miro

Peter
02.06.08, 15:46
Anderen seine Distribution zur Verfügung stellen

Guten Tag,

mit NFS und iSCSI werden Sie Ihre eigene Distribution erstellen und diese anderen RPS Nutzern zur Verfügung stellen können. Wir denken dass dies zum Beispiel für Spiele sehr interessant sein kann, mit spezifischer Vorkonfiguration und bestimmten Maps zum Beispiel. So kann ich dann wenn ich Heute Abend ein bestimmtes Spiel mit einer bestimmten Map spielen will meinen RPS mit einer entsprechenden Distribution reinstallieren und gleich loslegen.

F: Wer kann eine Distribution erstellen und sie anderen zur Verfügung stellen?
A: Jeder.

Könnt Ihr euch noch andere Anwendungsmöglichkeiten auf dieser Ebene vorstellen? Ich weiss nicht, vielleicht eine Version von Debian mit spezifischen Diensten die die anderen gerne verwenden würden?

Allgemein gesagt, OVH würde die Basisdistributionen zur Verfügung stellen und es euch erlauben, die vorbereiteten oder angepassten Distributionen den anderen Nutzern zur Verfügung zu stellen.

Mit freundlichen Grüssen

Octave

Peter
02.06.08, 14:30
NFS und das Backup

Guten Tag,

wir werden ein 2. Backup als Snapshot hinzufügen, damit man wenigstens 2 Tage zurück kann. Derzeit hat man 1 Snapshot unter NFS.

Wie sind eure Eindrücke? Ist ein RPS besser als ein vergleichbarer dedizierter Server?

Mit freundlichen Grüssen

Octave


rXXXXX ~ # df
Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
/dev/nfs 10246096 1168024 9078072 12% /
shm 237340 0 237340 0% /dev/shm
rXXXXX ~ # cd /
rXXXXX / # ls -al
total 60
drwxr-xr-x 17 root root 20 mai 30 14:14 .
drwxr-xr-x 17 root root 20 mai 30 14:14 ..
drwxr-xr-x 2 root root 126 fév 26 16:17 bin
drwxr-xr-x 2 root root 12 mai 30 12:09 boot
drwxr-xr-x 11 root root 1493 mai 30 14:14 dev
drwxr-xr-x 48 root root 147 mai 31 14:40 etc
drwxr-xr-x 9 root root 11 mai 30 15:32 home
drwxr-xr-x 8 root root 120 fév 26 16:30 lib
drwxr-xr-x 4 root root 5 fév 14 2006 mnt
drwxr-xr-x 2 root root 3 fév 14 2006 opt
dr-xr-xr-x 94 root root 0 mai 30 14:14 proc
drwx------ 4 root root 31 mai 30 21:04 root
drwxr-xr-x 2 root root 144 mar 12 14:36 sbin
drwxr-xr-x 11 root root 0 mai 30 14:14 sys
drwxrwxrwt 5 root root 9 mai 31 2008 tmp
drwxr-xr-x 13 root root 14 avr 11 16:25 usr
drwxr-xr-x 13 root root 15 jun 2 2006 var
rXXXXX / # cd .zfs

(man muss wirklich alles eingeben, es ist ein unsichtbares Verzeichnis)

rXXXXX .zfs # ls -al
total 2
dr-xr-xr-x 3 root root 3 mai 30 10:52 .
drwxr-xr-x 17 root root 20 mai 30 14:14 ..
dr-xr-xr-x 2 root root 2 mai 30 10:52 snapshot
rXXXXX .zfs # cd snapshot/
rXXXXX snapshot # ls -al
total 2
dr-xr-xr-x 3 root root 3 mai 30 10:52 .
dr-xr-xr-x 3 root root 3 mai 30 10:52 ..
drwxr-xr-x 17 root root 20 mai 30 14:14 2008-05-30
rXXXXX snapshot # date
sam mai 31 15:19:33 CEST 2008
rXXXXX snapshot # cd 2008-05-30/
rXXXXX 2008-05-30 # ls -al
total 60
drwxr-xr-x 17 root root 20 mai 30 14:14 .
dr-xr-xr-x 3 root root 3 mai 30 10:52 ..
drwxr-xr-x 2 root root 126 fév 26 16:17 bin
drwxr-xr-x 2 root root 12 mai 30 12:09 boot
drwxr-xr-x 11 root root 1493 mai 30 14:14 dev
drwxr-xr-x 48 root root 144 mai 30 14:40 etc
drwxr-xr-x 8 root root 10 jui 4 2006 home
drwxr-xr-x 8 root root 120 fév 26 16:30 lib
drwxr-xr-x 4 root root 5 fév 14 2006 mnt
drwxr-xr-x 2 root root 3 fév 14 2006 opt
drwxr-xr-x 2 root root 2 mai 30 14:14 proc
drwx------ 4 root root 29 mai 30 14:22 root
drwxr-xr-x 2 root root 144 mar 12 14:36 sbin
drwxr-xr-x 2 root root 2 mar 10 11:36 sys
drwxrwxrwt 4 root root 5 mai 30 15:18 tmp
drwxr-xr-x 13 root root 14 mai 30 14:13 usr
drwxr-xr-x 13 root root 15 jun 2 2006 var
rXXXXX 2008-05-30 # diff -u etc/passwd /etc/passwd
--- etc/passwd 2008-05-30 14:13:42.447232564 +0200
+++ /etc/passwd 2008-05-30 15:32:19.663528498 +0200
@@ -38,3 +38,4 @@
ldap:x:439:439:added by portage for openldap:/usr/lib/openldap:/usr/sbin/nologin
proftpd:x:102:505:added by portage for proftpd:/dev/null:/sbin/nologin
tcpdump:x:103:507:added by portage for tcpdump:/dev/null:/sbin/nologin
+zzzzzzzz:x:1000:100:zzzzzzz:/home/zzzzzzzz:/bin/false

mathias
15.05.08, 10:25
Hallo,

Morgen abend werden die Arbeiten auf den 197er RPS abgeschlossen sein. Wir
werden folgende Projekte wieder aufnehmen:
- RPS2: (wir haben momentan 100 RPS2, die bereit sind und pingen)
Wir müssen den Übergang von RPS1 auf RPS2 fertigmachen und dann können wir
Bestellungen aufnehmen.
Im Manager wird es bei der Bestellung eines RPS2 die Option geben "Ich will
einen RPS1 auf RPS2 umstellen", und dies wird dann 3 Minuten später gemacht
sein.
Nur RPS1 die iSCSI v2 nutzen können umgestellt werden.
- ISCSI v2 ist für Neubestellungen und -installationen aktiviert. Für alle
anderen werden wir in 3-4 Wochen sehen, wie wir das machen.
- NFS ist bereit, sagen wir nächste Woche? Wir müssen die Bereitstellung von
Snapshots aus dem Manager heraus beenden.
- Wir haben das MAC-Problem auf den filern gelöst.
- Es bleibt ein Problem auf den ISCSI-targets unter Solaris. Es gibt da
einen Bug, der bewirkt daß das ISCSI abstürzt. Dann stirbt die Verbindung
zwischen dem SAN und den ISCSI-proxies, die ISCSI-Server bemerken dies und
machen "Harakiri". Dies erlaubt es, den Wechsel zu einem
read-only-Dateisystem zu vermeiden. Wir werden:
- die ISCSI-Kernel neu patchen um den Harakiri-kernelpanic durch ein "sleep"
zu ersetzen und etwas saubereres zu machen
- Wir haben einen Bug in den iSCSI-Targets gefunden, der in der neuesten
OpenSolaris-Version behoben wurde. Wir werden SUN bitten, diesen Patch nach
Solaris zurückzuportieren (So wie sie es für das NFS gemacht haben).
Wahrscheinlich hängt dies auch mit dem Speicherbedarf von ZFS zusammen,
welches das gesamte RAM des Filers in Beschlag nimmt. (auch bei 64GB RAM
belegt es 80%) und manchmal braucht iSCSI plötzlich und sofort viel
Speicher, dieser wird nicht schnell genug wieder freigegeben und das
iSCSI-target hängt sich auf. Das Target startet nach etwa 3-4 Sekunden neu,
aber dies ist bereits zuviel, so daß sich die proxies auch aufhängen.
- Wir arbeiten an den persönlichen Backups auf iSCSI v2.
Ziel ist es, im Manager eine "hier klicken um das Backup jetzt zu
erstellen"-Funktion zu haben und/oder "Backups an diesem Wochentag
ausführen". Wir bewahren insgesamt 2 Backups auf. Und dies alles per ftp
verfügbar. Bleibt nichts als das alles zu programmieren.

Mit freundlichen Grüßen,
Octave

Peter
09.05.08, 10:20
RPS 197

Wir arbeiten in 3 Richtungen:
- Die Reinstallation der RPS
- Das Zurückspielen des Backup
- Arbeiten an dem defekten Filesystem

Das 1. ist erledigt.
Das 2. läuft aber es dauert sehr lang.
Beim 3. müssen wir sehen ob wir mit den 12 Platten des Filesystems etwas machen können um möglichst aktuelle Daten zurückzugewinnen. Es gibt sehr wenig Hoffnung aber es wäre möglich.
http://www.opensolaris.org/jive/thre...ssageID=220125
Wir installieren einen Filer mit OpenSolaris anstatt Solaris, den Build 78, und werden dann schauen ob wir mit den Festplatten zu einem Zeitpunkt einige Sekunden vor der Korruption der Daten zurückkehren können. Wenn das klappt ist zwar auch nicht alles wiederherstellbar, aber es wäre auf jeden Fall besser als das Backup vom Sonntag.

Octave

Peter
09.05.08, 10:14
RPS 197

Der Aufbau des Filesystem vom Backup aus ist sehr langsam. Es wird wahrscheinlich die ganze Nacht oder sogar länger dauern.

Um eine Panne der RPS der Kunden, die über ein eigenes Backup verfügen, zu verhindern, werden wir alle RPS von 197 auf der neuen iSCSI v2 Plattform installieren. Dies wird es den Kunden erlauben die RPS schnell wieder in Betrieb zu nehmen.

Sobald wir mit der Wiederherstellung des Backups fertig sind werden wir den Kunden die Möglichkeit geben Ihre Daten über iSCSI abzurufen.

Die Version 2 von iSCSI wird dieses Problem nicht mehr haben da jeder Kunde dort sein eigenes Filesystem auf dem SAN hat (anstatt eines grossen zwischen 230 Kunden aufgeteilten Filesystems).

Die Nacht wird lang...

Peter
09.05.08, 10:14
RPS 197

Guten Tag,

wir haben ein schweres Problem mit allen RPS die auf 197 installiert sind. Es sind 167 RPS von diesem Problem betroffen. Der älteste betroffene RPS wurde vor 18 Tagen installiert. Der jüngste vor 10 Tagen.

Die Meldung dazu:
http://forum.ovh.de/showthread.php?t=3731

Wir haben heute Nacht, Morgen und Nachmittag Wartungen auf dem SAN das die RPS von 196 und 197 verwaltet durchgeführt. Am späten Nachmittag hat sich das SAN in Default gesetzt und wir mussten vor Ort eingreifen. Anscheinend ist ein Hardwareproblem die Ursache des Problems. Wir haben die Shelfs ausgetauscht und wir haben das SAN neu gestartet. Das Filesystem von 196 hat keine Probleme. Alles läuft wieder. Aber auf 197 haben wir ein schweres Problem: trotz eines RAID-1 über 3 Platten haben mehrere Festplatten korrumpierte Daten und das Filesystem mountet nicht.

root@filerz3:~# zpool status -x
pool: filer197
state: FAULTED
status: The pool metadata is corrupted and the pool cannot be opened.
action: Destroy and re-create the pool from a backup source.
see: http://www.sun.com/msg/ZFS-8000-CS
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
filer197 FAULTED 0 0 4 corrupted data
mirror ONLINE 0 0 0
c1t20d0 ONLINE 0 0 0
c1t21d0 ONLINE 0 0 0
c1t22d0 ONLINE 0 0 0
mirror ONLINE 0 0 2
c1t23d0 ONLINE 0 0 4
c1t24d0 ONLINE 0 0 4
c1t25d0 ONLINE 0 0 4
mirror ONLINE 0 0 2
c1t26d0 ONLINE 0 0 4
c1t27d0 ONLINE 0 0 4
c1t28d0 ONLINE 0 0 4
mirror ONLINE 0 0 0
c1t29d0 ONLINE 0 0 0
c1t30d0 ONLINE 0 0 0
c1t31d0 ONLINE 0 0 0

Die Checksum auf dem 2. und 3. RAID-1 ist nicht korrekt aber vor allem ist die Checksumme bei 3 Festplatten von 2 RAID-1 nicht korrekt!

Wir werden vom Backup von Sonntag aus arbeiten aber es wird mehrere Stunden eventuell sogar noch länger dauern um das Backup zu nehmen und ein Filesystem daraus zu machen (aktuell hat das Backup die Form einer Datei, also binär. Wir werden es mit den ZFS Befehlen zreceive/zsend wiederherstellen).

Mit freundlichen Grüssen

Octave

Peter
07.05.08, 11:42
iSCSI v2

Hallo,

die iSCSI v2 Infrastruktur wird diese Woche für die Reinstallationen bereit sein.
NFS ziemlich sicher Ende der Woche in beta.

Mit freundlichen Grüssen

Miro

Peter
07.05.08, 11:36
Schliessung der RPS

Guten Tag,

wir richten in den nächsten 30 Minuten die Schliessung der RPS Server bei ausbleibender Verlängerung ein (bis jetzt liefen diese nicht ab). Es ist dann so wie bei den dedizierten Servern.

Octave

Peter
07.05.08, 11:33
Guten Tag,

die neuen Kunden werden auf der neuen v2 Infrastruktur installiert. Bis jetzt nichts besonderes zu berichten.

Für die alten RPS Kunden schauen wir dass eine Reinstallation eines RPS dann direkt auf der v2 geschieht. Sobald alles gemacht ist werdet Ihr euren RPS reinstallieren und die Infrastruktur wechseln können.

Für die Kunden die nicht reinstallieren können werden wir Fall für Fall nach einem Prozess für die Umstellung schauen.

MfG

Octave

Peter
24.04.08, 17:20
RPS USB Sticks

Wir haben einige Probleme mit der Einrichtung. Wir schauen nach was die Ursache ist. Im Test gab es keine Probleme, in Produktion sorgt das Anstecken des Sticks dafür dass der RPS abschmiert (auf dem alten und dem neuen Kernel). Wir fixen das.

Octave

Peter
24.04.08, 16:10
Einrichtung des SWAP auf RPS (Einfache Version)

Guten Tag,

um den SWAP auf dem USB Stick nutzen zu können bringt bitte euren RPS auf den neuesten Stand, indem Ihr in - ganz einfach - rebootet. Der RPS wird dann wie ein dedizierter Server übers Netzwerk booten und den neuesten Kernel verwenden. Der neueste Kernel ist 2.6.24.5.

Wenn Ihr diesen Kernel (von OVH) habt, dann könnt Ihr den USB Stick als (sehr gut) gesicherten SWAP verwenden. In der Tat wird nämlich der USB Stick vom System als /dev/uba und nicht als /dev/sdb gesehen. So kommt es nicht zu Verwechslungen zwischen der iSCSI Festplatte und dem USB Stick und ihr verliert nicht die Daten eurer iSCSI Platte indem ihr diese als SWAP formatiert. Der alte Kernel erkennt den USB Stick nämlich als /dev/sdb, aber bei einem Reboot wird es im besten Fall nur abstürzen, im schlechtesten Fall wird die iSCSI Festplatte formatiert weil sie für den SWAP gehalten wird. Es ist also wichtig,

SEHR WICHTIG

den Kernel auf den neuesten Stand zu bringen.

Ich wiederhole es nochmal eindringlich: wenn Ihr den USB Stick als SWAP mit der alten Version des Kernels verwendet, dann kann es sein dass Ihr alle Daten eurer iSCSI Festplatte verliert! Mit dem neuen Kernel gibt es keine Probleme. Die Operation ist full-safe. Der USB Stick wird als /dev/uba erkannt und es gibt keine Möglichkeit der Verwechslung mit der iSCSI Festplatte unter /dev/sda.

Wenn Ihr den neuen Kernel verwendet könnt Ihr folgendes Skript herunterladen und ausführen. Dieses führt alle Erkennungen und Überprüfungen durch um den SWAP korrekt einzubinden:

# wget ftp://ftp.ovh.net/made-in-ovh/rps/add_swap.sh -O add_swap.sh
# sh add_swap.sh

Wir werden in 1 Stunde mit dem Einbau der USB Stocks beginnen. Sobald dies erfolgt ist läuft das Skript korrekt durch und Sie können danach 512 MB SWAP verwenden.

# sh add_swap.sh
-----------------------------------------------------------
RPS Real Private Server
Einrichtung des SWAP von 512 MB

total used free shared buffers cached
Mem: 478048 97920 380128 0 4096 76620
-/+ buffers/cache: 17204 460844
Swap: 0 0 0


Der SWAP befindet sich auf dem vom System als /dev/uba gesehenen USB Stick.

1. ÜBERPRÜFUNG DES KERNELS (VERIFICATION DU NOYAU)
Dazu müssen Sie unter 2.6.24.5-xxxx-std-ipv4-32 sein.

Auf dem Server haben wir:
Linux rXXXXX.ovh.net 2.6.24.5-xxxx-std-ipv4-32 #1 SMP Wed Apr 23 17:03:49 CEST 2008 i686 GNU/Linux
... OK

2. USB STICK ANGESCHLOSSEN? (LA CLE USB CONNECTE)
... OK

3. USB STICK BEREITS VERWENDET? (LA CL2 USB DEJA UTILISEE)
... OK

Go ...

4. FORMATIERUNG UND INSTALLATION DES STICKS (FORMATAGE ET INSTALLATION DE LA CLE)

Der USB Stick wird in 5 Sekunden formatiert
5 4 3 2 1 ... Go ...

Formatierung des Sticks:
Setting up swapspace version 1, size = 512746 kB
no label, UUID=78ef48d6-8f0f-4dec-86c4-0e127c0e5542
Montage de la SWAP:
Configuration de /etc/fstab

Der USB Stick wurde installiert

5. ÜBERPRÜFUNG (VERIFICATION)

Filename Type Size Used Priority
/dev/uba partition 1006584 0 -8

total used free shared buffers cached
Mem: 478048 98460 379588 0 4100 76620
-/+ buffers/cache: 17740 460308
Swap: 512584 0 512584

Mit freundlichen Grüssen

Octave

Peter
24.04.08, 10:26
Installation der USB Sticks und Update des Kernel

Hallo,

Morgen im Laufe des Tages werden wir die USB Sticks installieren. So könnt Ihr dann einen lokalen Swap auf den RPS haben.

Um dies zu tun werden wir _alle Server_ im Netboot mit dem neuesten Kernel (2.6.24.5) booten nachdem der USB Stick eingebaut wurde.

Der Stick wird auf dem Server als /dev/uba sichtbar sein. Um ihn zu verwenden muss der Server reinstalliert weren oder man fügt ihn von Hand hinzu (partitionieren, filesystem erstellen und in der fstab hinzufügen).

Wenn Ihr den Kernel auf der Festplatte updaten wollt dann muss eure lilo.conf dieser hier ähneln:

[...]
image=/boot/bzImage-2.6.24.5-xxxx-grs-ipv6-32
label=linux
read-only
root=/dev/ram0
initrd=/initrd-iscsi.img
append="libusual.bias=ub"

Bis Morgen

Miro

PS: Um den USB Stick zu konfigurieren nachdem er installiert wurde genügt es folgendes zu kopieren und einzufügen:

=========
parted /dev/uba mklabel msdos
SIZE=`parted /dev/uba print | grep megabytes | sed 's/^.*-//'|sed 's/ mega.*//'`
parted /dev/uba mkpart primary linux-swap 0 $SIZE
mkswap -v1 /dev/uba1
swapon /dev/uba1
echo "/dev/uba1 none swap sw 0 0" >> /etc/fstab
=========

Peter
23.04.08, 15:56
vKVM für RPS Server verfügbar

Hallo,

Ihr könnt ab sofort den vKVM Modus auf euren RPS Servern verwenden.

Wenn Ihr vKVM noch nicht kennt, hier einige kleine Erklärungen dazu:
http://www.ovh.de/items/virtual_kvm.xml

Um es zu verwenden genügt es, vKVM bei eurem Server im Manager in der Rubrik "Dienstleistungen", "Netboot" auszuwählen und den Server neu zu starten.

MfG

Miro

Peter
16.04.08, 14:44
Ubuntu Desktop

Hallo,

Die Distribution Ubuntu 7.04 Desktop ist nun für die RPS Server verfügbar.
Mit Ubuntu Desktop können Sie sich mit dem Programm NX Client mit einem graphischen Desktop (in diesem Fall Gnome) auf dem Server verbinden.

Siehe dazu auch folgende Hilfe:
http://hilfe.ovh.de/UbuntuDesktopAllgemein

MfG

Guillaume

Peter
15.04.08, 10:58
SLA/noSLA: 192/195 195/199

Guten Tag,

wir haben gerade die Einrichtung von SLA und NoSLA auf den iSCSI Servern der RPS beendet. Wir haben einige Kunden mit einer sehr grossen Festplattennutzung in den NoSLA Modus umgestellt. Dies kam zum Beispiel im Fall von Dateitauschservern vor die viele gleichzeitige Verbindungen zum iSCSI Server machten.

Ab jetzt ist es so dass wenn ein Kunde die Platten sehr intensiv nutzt er auf NoSLA umgestellt wird (derzeit erfolgt die Umstellung noch von Hand).

Was bedeuten SLA und NoSLA?
---------------------------
Im NoSLA Modus setzen wir Verzögerungen auf die Antworten des iSCSI Servers. Anstatt sofort zu antworten fügen wir 100 ms Lag hinzu. Das ist alles. Im SLA Modus gibt es keine Verzögerung.

Wir haben die Option auf den Netzen 192/195 und 196/199 hinzugefügt. Die Funktionalität der RPS, SLA und NoSLA ist (meiner Meinung nach) gar nicht schlecht. Aber wie immer hätte ich dazu gerne euer Feedback.

Mit freundlichen Grüssen

Octave

Peter
14.04.08, 11:09
QoS & Co

Die Idee von SLA/NoSLA fürs iSCSI ist vielleicht nicht schlecht. Eigentlich sind das nur lesende oder schreibende Operationen pro Sekunde. Um es einfach zu sagen, wir haben 50 RPS pro Land (DE/FR/ES/UK) kostenlos abgegeben, und die Nutzer machen Dinge mit den Maschinen die mit einer "normalen" RPS Nutzung nichts mehr zu tun haben. Da sie nichts zahlen müssen ist es ihnen egal, und sie überlasten die Maschinen auf Teufel komm raus. Da habe ich nun einige abgeschaltet und es läuft besser. Aber es hat uns immerhin gezeigt dass es Nutzungsarten gibt die die Infrastruktur destabilisieren können. Aber das werden wir regeln, wir wissen bereits wie; es müssen nur noch die Tests abgeschlossen werden. Wenn wir erkennen dass ein Kunde über einen zu langen Zeitraum zu viele Operationen pro Sekunde macht, dann müssen wir ihn auf ein langsameres iSCSI umstellen. Es wird demjenigen wohl egal sein, denn da seine Nutzung des RPS eh nichts mit einer Qualitätsnutzung wie Webhosting & co. zu tun hat wird Best-Effort ihm genügen.

Octave

Peter
14.04.08, 11:00
QoS & Co

Hallo,

vielen Dank für eure Antworten.

Derzeit läuft es gut mit 100 Mbit/s, theoretisch gibt es keine Probleme. Theoretisch weil es einige RPS gibt die es schaffen den iSCSI zu überlasten. Wir werden in der Richtung der Beschränkung von Kunden die es übertreiben weiter machen, und nicht für alle Kunden. Denn im Moment läuft es ja gut.

Mit freundlichen Grüssen

Octave

Peter
14.04.08, 10:57
QoS & Co

Hallo,

wir haben verschiedene Tests auf den Netzen 192/195 und 196/199 durchgeführt. Auf den Netzen 192/195 haben wir derzeit keine Probleme. Alles funktioniert perfekt. Auf den Netzen 196/199 haben wir aber einige Kunden die es schaffen, zeitweise den iSCSI Server zu destabilisieren. Dies liegt an einer bestimmten Nutzungsart des Servers (eine Software die wir in der Beta nicht getestet haben).

Wir haben Tests mit dem QoS durchgeführt um diese Art der Nutzung zu beschränken aber das iSCSI Protokoll erkennt den Eingriff des QoS als "drop". Vereinfacht gesagt destabilisiert das den Server. Eigentlich ist das nicht schlimm, wir wollen ja einen Kunden beschränken der den iSCSI Server überlastet. Aber diese Destabilisierung verursacht eine Überlastung des iSCSI Servers, der deswegen mehr als normalerweise beansprucht wird.

Wir werden also nun die QoS von 'DROP' auf 'WAIT' umstellen und die Pakete derer die den Server überlasten verzögern. Wir sollten die Tests innerhalb weniger Tage auf einer Testplattform validieren können.

Ich habe mich aber heute morgen gefragt ob es nicht einfacher und für alle klarer wäre das Netzwerkinterface des RPS von 100 Mbit/s auf 10 Mbit/s umzustellen. So haben wir ein natürliches und perfektes 'WAIT', das Angebot ist auf der Seite klar und es gibt keine weitere Aufteilung wie 100 Mbit/s der RPS und 10 Mbit/s das iSCSI oder QoS oder wie auch immer. Was denkt Ihr davon?

Mit freundlichen Grüssen

Octave

Peter
07.04.08, 11:29
Neuer RPS Kernel

Hallo,

in dem neuen Kernel wurden 2 neuen Funktionen implementiert:
- Änderung der Frequenz mit governor ist standardmässig "conservative"
- mtd Treiber der es erlaubt, Videospeicher zum Beispiel als swap zu nutzen

Die Änderung der Frequenz ist nur auf den RPS 2 möglich.
Ihr könnt Informationen zur Frequenz in /sys einsehen:
# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
1900000

Wir raten derzeit noch von einer produktiven Nutzung des mtd Treibers ab, dieser sollte nur zu Testzwecken genutzt werden.
Sobald die Erkennung der von der Videokarte verwendeten Speicherbereiche automatisch erfolgt und es keine Auswirkungen auf den Produktivbetrieb gibt werden wir es in eine neue Distribution einfügen.

Den Kernel gibt es auf ftp.ovh.net:
ftp://ftp.ovh.net/made-in-ovh/bzImag...4-32-minipower

MfG

Miro

Peter
07.04.08, 11:08
RPS 2: Die Innovation geht weiter

Hallo,

nach dem auf einem sparsamen Intel Prozessor basierenden RPS 1 geht die Innovation nun mit dem in die Betaphase kommenden RPS 2 weiter.

Der RPS basiert auf einem AMD Dual BE-2300 Prozessor mit 2x 1.9 GHz und 1 GB RAM, 100 Mbit/s Netzwerk und 10 GB iSCSI Speicherplatz.

Woraus besteht die Innovation?
------------------------------
AMD hat eine Technologie entwickelt die es erlaubt weniger Strom zu verbrauchen wenn der Prozessor nicht verwendet wird. Technisch gesehen verfügt Linux über mehrere Programme um die Leistung des BE-2300 an den realen Bedarf anzupassen. Die Rechenleistung des Prozessors wird angepasst, indem die Betriebsfrequenz des Prozessors im Betrieb lastabhängig geändert wird.

Hier die Programme:
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
conservative ondemand userspace powersave performance

Wir wählen "performance" um die maximale Leistung zu erhalten:
# echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Die CPU läuft mit 2x 1.9 GHz:
# grep "^cpu MHz" /proc/cpuinfo
cpu MHz : 1900.000
cpu MHz : 1900.000

Wir wechseln nun einmal zu "powersave", das dazu dient Energie zu sparen:
# echo powersave > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Die CPU Frequenz ist nun 2x 1.00 GHz:
# grep "^cpu MHz" /proc/cpuinfo
cpu MHz : 1000.000
cpu MHz : 1000.000

Und jetzt verwenden wir den "ondemand" Modus, der die CPU Frequenz in Abhängigkeit der benötigten Leistung anpasst:
# echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Es läuft nichts auf dem Server, darum beträgt die Frequenz 2x 1 GHz.
# grep "^cpu MHz" /proc/cpuinfo
cpu MHz : 1000.000
cpu MHz : 1000.000

Wir starten einige Anwendungen:
# bzip2 -d linux-2.4.32.tar.bz2 -c >> /dev/null &
[1] 4116
# grep "^cpu MHz" /proc/cpuinfo
cpu MHz : 1000.000
cpu MHz : 1000.000
[...] 3 Sekunden später
# grep "^cpu MHz" /proc/cpuinfo
cpu MHz : 1900.000
cpu MHz : 1900.000
[...] 15 Sekunden später
# grep "^cpu MHz" /proc/cpuinfo
cpu MHz : 1900.000
cpu MHz : 1900.000
[1]+ Done bzip2 -d linux-2.4.32.tar.bz2 -c >>/dev/null
# grep "^cpu MHz" /proc/cpuinfo
cpu MHz : 1800.000
cpu MHz : 1800.000
# grep "^cpu MHz" /proc/cpuinfo
cpu MHz : 1000.000
cpu MHz : 1000.000

Man kann sehen dass als der Bedarf bestand die CPU selbst Ihre Betriebsfrequenz auf Maximum gestellt hat, und sobald kein Bedarf mehr bestand die Frequenz wieder reduziert hat.

Der Modus "conservative" funktioniert wie "ondemand", aber mit einer grösseren Verzögerung/Trägheit beim erhöhen oder erniedrigen der Frequenz.

"userspace" erlaubt es die Frequenz über ein Programm in Echtzeit zu beeinflussen. Nicht mehr der Prozessor entscheidet, sondern ein externes Programm das überwacht was auf dem Server passiert und die Frequenz je nach Bedarf anpasst.

Welche Rechenleistung für welche Energieersparnis?
--------------------------------------------------
Die AMD BE-2300 CPU ist so leistungsfähig wie ein Intel Pentium 2180 (d.h. ein Start100M). Sein Energieverbrauch ist auch der gleiche wie beim 2180. Wenn man jedoch "ondemand" aktiviert verbraucht der Server 10% weniger Energie. Intel bietet auch Techniken um die Frequenz je nah Bedarf anzupassen, dabei bleibt der Verbauch jedoch gleich (exakt gleich...) Dies liegt daran dass bei AMD die CPU und der Speicherkontroller (Chipset) eins sind und bei einer Absenkung der Frequenz beides betroffen ist. Im Fall von Intel passt nur die CPU die Frequenz an. Der Chipset läuft dabei weiter mit der nominellen Frequenz.

10%, ist das viel oder nicht? Nun ja, besser als nichts, und fast für die Hälfte des Tages. Denn Nachts und früh Morgens gibt es üblicherweise weniger zu tun. Das wird sehr interessant sein die exakten Zahlen dazu zu sehen, je nachdem was auf dem RPS 2 läuft. Wie viele Stunden am Tag läuft der RPS mit 1.0 GHz, wie viele mit 1.9GHz?

Und wie geht es weiter? In punkto Energieeinsparung testen wir die neue 45 nm Generation von Intel.
Eine kleine CPU mit einer grossen Zukunft (RPS 3??)... :

model name : Intel(R) Core(TM)2 Duo CPU E8200 @ 2.66GHz
stepping : 6
cpu MHz : 2648.000
cache size : 6144 KB

Mit freundlichen Grüssen

Octave

Peter
03.04.08, 10:22
Feedback

Hallo,

wie ist das derzeitige Feedback?

Von unserer Seite:

- Wir hatten ein Problem mit dem iSCSI Server von 202/203 wegen eines defekten Kabels in der Infrastruktur des SAN. Gestern Abend haben sich die Server aufgehängt. Aber Dank des neuen "arakiri" Kernels kein read-only. Miro hat unsere iSCSI Server so gepatcht dass wenn die Verbindung zwischen dem SAN und den iSCSI unterbrochen wird, diese Unterbrechung über einen Kernel Panic auf dem iSCSI Server gemacht wird. Auf diese Weise kommt es nicht zum read-only.
- Wir haben noch ein Problem auf 192/193. Wir fangen an das Problem zu verstehen aber wir finden noch keine Lösung. Es wird einfacher werden wenn wir die Netzwerkkarten für die iSCSI Server bekommen haben.
- Wir testen NFS, es funktioniert ohne Probleme. Warum bieten wir es eigentlich noch nicht an?
- Ich hatte keine Zeit das neue QoS anzuwenden. Da geht im Moment nicht allzu viel voran.
- Wir werden morgen eine Sache in Produktion nehmen und neue Optionen für die RPS hinzufügen.
- Wir müssen eine Idee testen die wir für iSCSI haben. Wenn das funktioniert wäre das ein Knaller

Mit freundlichen Grüssen

Octave

Peter
01.04.08, 14:00
News

Hallo,

wir testen gerade den RPS 1 mit NFS anstatt iSCSI. Der Fix funktioniert, es gibt keine Probleme mehr. In diesem Zusammenhang testen wir die Grenzen der Infrastruktur.

Deshalb verzögert sich aber der RPS 2 um einige Tage, auch wenn die Maschinen bereits in den Racks stehen.

Parallel dazu werde ich einen anderen Typ von QoS testen. Die Idee dazu hatten wir letzte Woche, ich weiss noch nicht ob ich es heute mache oder nicht.

Die Optionen im Manager (wie IRC & co) werden in einigen Tagen nicht mehr ausgegraut sein.

Wir testen auch auf 202/203 eine andere Architektur in Bezug auf iSCSI. Wir geben uns 7 Tage um zu einem Proof of Concept zu gelangen. Wenn es funktioniert wird die Verwaltung des zusätzlichen Speicherplatzes viel flexibler als derzeit möglich sein. In jedem Fall möchten wir euch innerhalb von 10 Tagen bis zu 1 TB anbieten können.

Mit freundlichen Grüssen

Octave

Peter
01.04.08, 11:57
Hallo,

wir haben heute einen "Fix" bekommen der das Problem des NFS auf dem SAN beheben sollte. Es handelt sich um einen ersten Fix der jetzt bei uns aber auch bei den Liefranten des SAN auf allen Plattformen getestet wird. Daraus wird dann anschliessend ein Patch werden. Es geht also voran.

MfG

Octave

Peter
20.03.08, 12:26
WICHTIG: "Stabile" Beta Version 0.99

Guten Tag,

der RPS 1 ist nun "stabil". Das bedeutet dass die Leistung und Funktionen die Sie derzeit haben denen nach der Einführung entsprechen.

Wir werden heute noch einige kosmetische Änderungen an der Infrastruktur vornehmen, damit alles sauber ist (wir haben während der Tests so viel hin und her geändert dass wir nun zu eine produktiven Infrastruktur zurückkehren müssen).

Der Start des Angebots ist für Heute vorgesehen. In allen Ländern in denen OVH präsent ist.

Danke für eure Feedbacks

Mit freundlichen Grüssen

Peter

Peter
20.03.08, 10:43
Guten Abend,

auf 194/195 haben wir ein spezielles QoS eingerichtet, das einen Schutz gegen die die es übertreiben erlauben sollte und trotzdem eine gute Performance bietet. Um die Dinge einfach auszudrücken: der tar-Test den Ihr zur Lastsimulation eingesetzt wird ist ein Plattenkiller, und wir haben die Herausforderung angenommen diesen in den Griff zu bekommen. Ich weiss nicht ob das jetzt gelungen ist oder nicht. Was uns aber interessiert ist ob die Kunden, die keine hohe Last erzeugen, einen korrekten Dienst erleben. Ist das Web schnell? Kommen die E-Mails schnell an? Ist die SQL Dazenbank ok? Von dem was wir von den Maschinen und der Aktivität im Netzwerk sehen scheint es ziemlich gut zu funktionieren, aber wir brauchen nun euer Feedback.

Danke

Octave

Peter
19.03.08, 13:50
iSCSI 194

Hallo,

ich habe nun QoS auf 194/195 eingerichtet. Normalerweise sollte es die - und nur die - beschränken die lesend zu viel Last erzeugen, und dabei trotzdem bei interessanten Zeiten bleiben. Ich habe das zumindest auf einigen RPS getestet. Könnt Ihr nochmal Last erzeugen, aber auch uns ein Feedback geben wenn Ihr eher eine normale "Web" typische Nutzung macht.

Vielen Dank

Octave

Peter
19.03.08, 10:49
Reboot des iSCSI Servers 194

Hallo,

wir werden den iSCSI Server vom Netz 194 rebooten.

Miro


Router

Hallo,

die Karten auf den Routern wurden umgestellt.

Octave

Peter
19.03.08, 10:44
Netz 194

Wir haben die Netzwerkkarten getauscht, jetzt rennt es. Könnt Ihr nochmal so viel Last wie möglich erzeugen?

Octave

r10226:/home# time rm -rf linux-2.6.24

real 0m3.397s
user 0m0.028s
sys 0m0.480s
r10226:/home# time tar xf linux-2.6.24.tar

real 1m31.595s
user 0m0.492s
sys 0m3.248s
r10226:/home# time rm -rf linux-2.6.24

real 0m0.537s
user 0m0.016s
sys 0m0.472s
r10226:/home# time tar xf linux-2.6.24.tar

real 1m17.333s
user 0m0.452s
sys 0m3.424s
r10226:/home# time rm -rf linux-2.6.24

real 0m0.696s
user 0m0.012s
sys 0m0.480s
r10226:/home# time tar xf linux-2.6.24.tar

real 0m58.575s
user 0m0.452s
sys 0m3.632s

Peter
18.03.08, 13:55
Unterbrechung des iSCSI Servers auf dem Netz 194

Hallo,

wir modifizieren die Konfiguration des iSCSI Servers des Netzes 194. Es wird 5 Minuten Unterbrechung geben.

MfG

Miro

Peter
18.03.08, 10:06
Neustart 194/195

Hallo,

wir werden heute Morgen Tests auf den Netzen 194 und 195 machen. Diese werden unterbrochen und dann nach und nach wieder eingeschaltet.


MfG

Octave

Peter
14.03.08, 10:36
Guten Tag,

wir sind nun auf einer 2/4 Infrastruktur, und ich glaube das merkt man:

real 0m57.586s
user 0m0.404s
sys 0m3.380s

Normalerweise gibt es keine Probleme mehr. Das ist die Theorie. Nun warten wir auf wieder auf euer Feedback. Bitte antwortet auf die Fragen um unserem armen Admin zu helfen die Probleme zusammenzufassen.

Wir haben mehrere Fragen:
- Gibt es noch jemanden bei dem es langsam ist?
- Sind die RPS 194/195 langsamer als die RPS 192/193?
- Könnt Ihr wieder damit anfangen auf euren RPS Lasttests laufen zu lassen? Aber wirklich so viel wie möglich?
- Kommt es noch vor dass der RPS sich aufhängt?
- Kommt es noch vor dass der RPS im read-only landet?
- Habt Ihr noch Probleme bei der Reinstallation?
- Habt Ihr noch andere hier nicht aufgeführte Probleme?

Wir warten auf eure Rückmeldung! Und wir bereiten die Installation von OCO vor um eure RPS zu monitoren um zu erfahren ob alles in Ordnung ist oder es ein Problem gibt. Dann wollen wir alle kleinen Probleme beheben die Ihr haben könnt.

Das Ziel ist es im Laufe der nächsten Woche mit der Kommerzialisierung des RPS 1 Angebots in Frankreich zu beginnen.

Vielen Dank an Alle!

Mit freundlichen Grüssen

Octave

Peter
14.03.08, 09:51
Umstellung auf das neue SAN

Guten Abend,

wir werden nun die Umstellung der RPS von 192 und 193 auf das neue SAN durchführen. Die Umstellung wird in kürzester Zeit (einige Minuten) durchgeführt und Ihr solltet nur einen Freeze auf Ebene der RPS haben.

Wir fangen in circa 15 Minuten zuerst mit 193 an, danach 192. Wir halten euch über die Fortschritte auf dem laufenden.

Miro

Update: 13.03.08 19:00

Die Umstellung von 192 ist beendet. Es ist jedoch schlecht gelaufen weil ein Timeoutparameter von unserer Seite aus falsch definiert war. Wir entschuldigen uns für diese Panne.

Wir werden alle Server auf 192 rebooten.

Miro

Update: RPS 14.03.08 02:25

Der Reboot hat die Probleme auf Seiten von iSCSI nicht beheben können. Wir werden das SAN das sich um 194 und 195 kümmert rebooten.

Miro

Peter
11.03.08, 12:18
WICHTIG: Bitte updated eure RPS

Hallo,

damit wir mit den Tests fortfahren können möchten wir euch bitten, euren RPS mit den neuen Startparametern und der neuen iSCSI Verwaltung auf den neuesten Stand zu bringen.

Um dies durchzuführen genügt es folgende Zeile (in 1 Zeile) per copy/paste einzufügen:

# wget ftp://ftp.ovh.net/made-in-ovh/dedie/...pdate-iscsi.sh -O /tmp/update-iscsi.sh && sh /tmp/update-iscsi.sh

Vielen Dank!

Mit freundlichen Grüssen

Octave

Peter
11.03.08, 12:14
Hallo,

in 5 Minuten werden wir damit beginnen die Daten für die RPS der Netze 192 und 193 umzukopieren.
Diese Server werden zwischen 06:00 und 10:00 nicht erreichbar sein. Dies wird es uns erlauben auf die finale Architektur beim SAN und den iSCSI Servern umzustellen.

Wir haben den iSCSI Daemon auf einem Teil der RPS dieser 2 Netze geupdated um zu überprüfen ob sie diese mehrere Stunden dauernde iSCSI Unterbrechung "überleben" können.

Wir halten euch über die Fortschritte auf dem Laufenden.

Mit freundlichen Grüssen

Miro

Peter
11.03.08, 12:09
Hallo,

gibt es noch Probleme bei den Reinstallationen? Oder funktioniert da jetzt alles?

Wir sind noch dabei Daten zu kopieren um das eine Filesystem des SAN auf 4 Filesysteme aufzuteilen, eines für je 250 Server.
Die Kopie läuft noch auf 192 und 193. Sobald alles abgeschlossen und konfiguriert ist werden wir die Tests wieder aufnehmen.

Mit freundlichen Grüssen

Octave

Peter
11.03.08, 12:05
Hallo,

wir sind dabei die Daten auf der Ebene des SAN umzukopieren. Wir wollten es diesmal schneller als bei den letzten Malen machen, deshalb werdet Ihr wahrscheinlich Verlangsamen im Vergleich zum Normalbetrieb bemerken.

Es verbleiben noch 6 bis 8 Stunden für die Kopie; dann werden wir heute Nacht die letzten Umstellungen machen.

MfG

Miro

Peter
11.03.08, 11:58
Hallo,

194 und 195 wurden umgestellt und man sollte bereits die Resultate davon sehen. 192 läuft im Moment und dann ist 193 dran. Vielleicht könnt Ihr einige schnelle tests machen um zu sehen ob 194 und 195 nun besser sind?

Auf unserer Seite haben wir einige Dinge bei den Servern geändert. Diese Resultate sollte man auch sehen können. Zum Beispiel wie man verhindern kann in read-only zu kommen... Zögert nicht uns dazu auch ein Feedback zu geben.

Wir arbeiten an den Distributionen um diese auf die Bedürfnisse der RPS mit den iSCSI Besonderheiten anzupassen.

Wir sind ein wenig spät dran aber noch im Zeitplan. Die Kopie dauert länger als vorgesehen da Ihr eure RPS ausgiebig nutzt. Ich vermute dass einige bereits die finalen Versionen Ihrer Seiten auf dem RPS installiert haben...

So. Diese Woche werden wir wissen ob man 1000 RPS auf einer 1/4 Infrastruktur betreiben kann oder ob wir zu 2/4 wechseln müssen. Insofern war dieser Betatest eine gute Entscheidung vor der Kommerzialisierung.

Mit freundlichen Grüssen

Octave

Peter
10.03.08, 13:01
Guten Abend,

in Folge eines auf dem SAN ausgeführten Befehls haben wir die Verbindung zwischen den iSCSI Servern und dem SAN verloren.
Wir sind gerade dabei die iSCSI Server neu zu booten um diese Verbindung komplett zurückzusetzen.
Wir werden anschliessend die RPS neu booten um wieder zu einem normalen Betrieb zurückzukehren.

Miro

Update 07.03. 01:10:

Wir haben alle Maschinen neu gebootet.
Diese sollten innerhalb von 10-15 Minuten - je nach benötigter Dauer für den Reboot/Check des Filesystems/Start - wieder erreichbar sein.

Peter
10.03.08, 12:52
Hallo,

anscheinend gibt es nun keine Probleme mehr bei der Reinstallation der RPS. Das System funktioniert korrekt.

Wenn es ein Problem gibt dann kann dies entweder am RPS selbst liegen (und dessen Besonderheiten bezüglich des timeout) oder daran, dass die Distribution noch nicht ausreichend auf den RPS abgestimmt ist.

Vielen Dank für euer Feedback!

Octave

Peter
06.03.08, 16:56
Wir hatten eine Unterbrechung auf 193 wegen eines Defekts eines Kabels. Es gab zuerst eine erste Unterbrechung von etwa 5 Minuten und danach nochmal etwa 30 Sekunden für den Tausch des Kabels.

Um einen Timeout von 24 Stunden anstatt 2 Minuten zu haben muss man initrd, iscsid und iscsiadm updaten.
Oder ansonsten die Maschine reinstallieren...

Miro

Peter
06.03.08, 16:46
Hallo,

194 wurde umgestellt, wir sind gerade dabei auch 195 umzustellen. Und 192/193 bleiben auf der alten Einstellung. Was ist das Ziel? Wir werden das SAN in 4 kleine Teile auftrennen anstatt ein grosses. Wir denken dass das Filesystem an sich in Bezug auf gleichzeitige Zugriffe ans Limit kommt, obwohl das SAN maximal mit 50% läuft.
Das Ziel ist es eine sehr hohe SAN Geschwindigkeit für euren RPS zu haben. Ich habe gestern 194 getestet und fand es schnell, aber ich hätte es lieber wenn wir die Tests nochmal durchführen wenn alles umgestellt worden ist. Dies dauert lange da es unter Last geschieht, bei einem Betrieb wie unter produktiven Bedingungen.

Wenn Ihr Probleme mit der Reinstallation habt dann liegt das daran dass das SAN zu lange benötigt. Unsere Installationsskripte der Distributionen sind für den Betrieb im Zusammenspiel mit einer Festplatte ausgelegt, und darum funktioniert es nicht wenn das SAN zu langsam ist. Zusammengefasst: wir sind dazu verdammt euch ein SAN zu liefern das so schnell wie eine Festplatte ist. Das ist ja auch das Ziel.

Wir haben die Windows Distribution für den RPS fertig. Aber zuerst werden wir die Arbeit am SAN abschliessen.

Ein Watchdog wird auf euren RPS installiert der es erlaubt festzustellen dass das Filesystem in read-only ist und dann den RPS automatisch rebootet. Ausserdem erlauben es die neuen iSCSI Parameter einen Timeout von 24 Stunden zu haben.

Wir haben die Absicherungen beim mounten der iSCSI Volumes aktiviert.

MfG

Octave

Peter
06.03.08, 16:28
Hallo,

in diesem Thread werde ich mal wichtige/interessante Infos der französischen RPS Mailingliste (wer des französischen mächtig ist und Interesse hat: rps-subscribe@ml.ovh.net Mail mit beliebigem Inhalt und Betreff - kann beides leer sein; zum abmelden: rps-unsubscribe@ml.ovh.net) einstellen, also die Ankündigungen von Octave und Miro und Infos zu Problemen und Störungen.

Peter