OVH Community, your new community space.

etat des lieux


bjo
16.05.08, 15:21
Nach dem ersten Reboot kam eine Mail von OVH: Reboot ausgeführt, Ping wieder da (was nicht der Fall war). 3 Minuten später eine Mail, dass der Server nicht auf Ping antwortet.

miro912
16.05.08, 15:17
War auch interesant das der Monitoring von OVH erst nach einer halben Stunde gemerkt hat das der Server weg ist, ich konnte schon etwa um etwa 13 Uhr festellen das da kein Ping mehr kommt, laut EMail von OVH die erst um 13.30 Uhr.

whyte
16.05.08, 15:15
Zitat Zitat von bjo
Mysql berichtete allerdings über corrupt tables.
die habe ich immer, ausser diesmal.

bjo
16.05.08, 15:08
Meiner ist nun auch wieder da (nach 2 Stunden), hab reiserfsck im rescue durchlaufen lassen, hat keine Fehler gefunden. Mysql berichtete allerdings über corrupt tables.

whyte
16.05.08, 15:07
Meine sind auch das erste mal sauber.

Aber komisch, ich habe gerade das Maillog am laufen, da versucht ein Mailserver von OVH an meinen zu schicken. An eine email Adresse, die OVH nicht kennen kann ?
Ob die da nen Fallback-Server laufen haben (Backup MX)?
Aber kann ja nicht sein, es sei denn, die übernehmen meine IP Adresse für die Zeit des Ausfalls ... was aber blöde wäre, denn ich blocke nach dem ersetn misslungen Zustellversuch die IP, dann würden da meine Mails auflaufen ...

miro912
16.05.08, 15:02
Meine Datenbanken haben das ganze anscheinend unbeschadet überstanden.
Wäre auch blöd wenn nicht, ich habe da Spielsüchtige auf meiner Seite die bestimmt einen Heulkrampf bekommen wenn nur ein Highscore weg ist

whyte
16.05.08, 14:57
einer von mir auch, der andere mag noch nicht ... grrrr
naja, sind die datenbanken wieder hin ... das ist immer ne arbeit

miro912
16.05.08, 14:56
So, meiner ist seid 3 Minuten wieder da, aber nichts genaues weis man nicht.

whyte
16.05.08, 14:20
dito, bis auf das bei mir auch schon kein login mehr möglich war

bjo
16.05.08, 14:11
Hard-Reboot, RPS pingt nun nicht mehr *grmbl*

bjo
16.05.08, 13:46
Der Wurm scheint momentan wirklich noch drin zu sein, leider. Ansich find ich die Idee des RPS immernoch gut, nur sollten die SANs irgendwann mal rund laufen.

whyte
16.05.08, 13:38
ne, ich glaube nicht mehr, dass es am RPS selbst bzw am Kernel liegt.
Ich vermute, es liegt eben an der Feinabstimmtun nach dem RPS -> Proxy, SAN was weiss ich, was da noch hängt.
Irgendwo ist auf jeden Fall noch ein Wurm drin.

Nur leider ist das nun auch mittlerweile so, dass meine Kunden die Situation um den RPS kennen und ich deshalb diesen auch nicht mehr weitervermieten kann, dumme Sache jetzt, weils nun wirklich eine endgeile Idee war.

miro912
16.05.08, 13:37
Zitat Zitat von bjo
Meiner lief am 198er auch tagelang. Stehen irgendwelche iscsi-Fehlermeldungen in den Logs?
Nein leider nicht, ich habe vorhin noch eine Mail an den Support geschrieben, ich hoffe das die sich das bald man anschauen.

bjo
16.05.08, 13:35
Meiner lief am 198er auch tagelang. Stehen irgendwelche iscsi-Fehlermeldungen in den Logs?

miro912
16.05.08, 13:34
Nein,sw.202.247/37 , mein auslaufender am 198 läuft noch.

bjo
16.05.08, 13:31
Du hängst am 197?

miro912
16.05.08, 13:29
Zitat Zitat von whyte
is wieder weg, beide

so siehts bei mir aus, wenn die kisten sich weghängen:
http://demo21.ovh.com/b2efcc2fd38be3...100prozent.JPG
meiner ist auch wieder weg, grummel, immerhin 24 Stunden und 22 Minuten gelaufen.

bjo
16.05.08, 13:24
Was sagen die Logs?

Meiner is grad auch halb weg, iscsi13/14 sollten ja ein Update der Konfiguration kriegen, und das läuft wohl nicht. Hab letzte Nacht Miro von OVH mal die URL zu meinem munin geschickt, die iowaits sind trotz iscsiV2 nicht besser geworden.

whyte
16.05.08, 12:59
is wieder weg, beide

so siehts bei mir aus, wenn die kisten sich weghängen:
http://demo21.ovh.com/b2efcc2fd38be3...100prozent.JPG

whyte
16.05.08, 08:38
nur die zwagsweise neuinstallation letzte Woche
Seid gestern ist mein neues Isgenug da, so dass ich am Wochenende, aber vielleicht auch heute schon, den einen umziehen kann.
Ich bin aber mit der Partitionierung so noch nicht zufrieden ...

Aber dann installiere ich den RPS mal neu ... und schaue dann.

bjo
15.05.08, 23:04
@whyte:

Hast du deine RPS mittlerweile neuinstalliert?

whyte
15.05.08, 14:01
Ja, der Realtime-Monitor ist nicht wirklich sooooo real ...
Warte mal 5 Min ...

miro912
15.05.08, 13:58
So, jetzt läuft er seid einer Stunde wieder, fragt sich nur wie lange noch. Laut Realtime-Monitor läuft der CPU wieder bei 100% Belastung.
Auf den anderen RPS lief die gleiche Installation selbst bei starken Traffic bei 7-10% CPU.

miro912
15.05.08, 12:55
Zitat Zitat von whyte
Achso, dann sollte ich vielleicht spasseshalber einen der 2 auch einfach mal neu machen ...

Ja, fail2ban wars net ;-)
Meiner ist gerade für ganze 19 Minuten gelaufen bevor er sich wieder verabschiedet hat.

Schon wieder eine Neuinstallation, nochmal meine 7 Gigabyte hochladen, naja.

whyte
15.05.08, 12:31
Achso, dann sollte ich vielleicht spasseshalber einen der 2 auch einfach mal neu machen ...

Ja, fail2ban wars net ;-)

bjo
15.05.08, 12:28
Zitat Zitat von whyte
Du meinst, nach einer Nueinstallation hing der RPS an einem anderen SAN ?

Meine 2 sind heute nach um 1 Uhr auch wieder ausgestiegen.
Ich habe jetzt fail2ban unter Verdacht und es bei einem mal ausgeschaltet.
Ja, nache der Neuinstallation hängt der RPS nun an einem anderen SAN. fail2ban rennt bei mir ohne Probleme.

whyte
15.05.08, 11:10
ich habe einen reboot veranlasst ... dauerte aber nun sind beide da, SAN ist beschreibbar, keine Probleme im Moment

miro912
15.05.08, 11:09
Zitat Zitat von whyte
hmm nein, beide laufen wieder rund ... ein paar datenbankfehler, aber die habe ich jedes mal ...
meiner ist immer noch nicht wieder da, hatte nur gesehen das in Deinen Rack wieder welche weg sind.

whyte
15.05.08, 11:07
hmm nein, beide laufen wieder rund ... ein paar datenbankfehler, aber die habe ich jedes mal ...

miro912
15.05.08, 11:00
Zitat Zitat von whyte
Ja, tat sie immer - bei beiden.
Beide sind jetzt auch wieder da, ging mal fix ;-)
Kann es sein das Deine beiden gerade wieder weg sind?

whyte
15.05.08, 10:54
Ja, tat sie immer - bei beiden.
Beide sind jetzt auch wieder da, ging mal fix ;-)

pendulum
15.05.08, 10:51
Klingt ziemlich übel, mein Beileid.
Die RPS brauchen einfach noch eine Reifephase anscheinend, bis alle Bugs entdeckt und bereinigt sind. Zur Zeit kommt's aber auch Knüppeldick von allen Seiten für OVH.

miro912
15.05.08, 10:48
Tu mir doch mal den Gefallen und gehe in den OVH-Manager ins Realtime-Monitoring und schaue ob da die CPU-Belastung auch auf 100% steht

whyte
15.05.08, 10:47
Zitat Zitat von miro912
rate ma mal wessen noch
Und ich hatte echt schon meine Anwendungen unter Verdacht. Aber auf 2 gleichzeitig, mit unterschiedlichen Konfigurationen.
Aber wenn deiner auch weg ist, dann liegts wohl an der Hardware.

Ich bin mal gespannt, in einer Mail von OVH war ja was von einer "Entschädigung" die Rede ...

Mittlerweile hält das nun 1 volle Woche an, in der beide Server keine 24 Stunden durchhalten ...

miro912
15.05.08, 10:45
Zitat Zitat von whyte
Nun sind wieder beide weg ...
rate ma mal wessen noch

whyte
15.05.08, 10:40
Nun sind wieder beide weg ...

miro912
15.05.08, 09:32
Zitat Zitat von whyte
Du meinst, nach einer Nueinstallation hing der RPS an einem anderen SAN ?

Meine 2 sind heute nach um 1 Uhr auch wieder ausgestiegen.
Ich habe jetzt fail2ban unter Verdacht und es bei einem mal ausgeschaltet.
Einer von meinen ist zur gleichen Zeit ausgefallen, der gleiche wie schon mal gleichzeitig mit Deinen.

whyte
15.05.08, 09:05
Du meinst, nach einer Nueinstallation hing der RPS an einem anderen SAN ?

Meine 2 sind heute nach um 1 Uhr auch wieder ausgestiegen.
Ich habe jetzt fail2ban unter Verdacht und es bei einem mal ausgeschaltet.

bjo
15.05.08, 01:38
So, neuinstalliert. Der RPS hängt nun an iscsi14(191) und nicht mehr am 198er-SAN.

Grade hing die Kiste dann mal:
May 15 01:25:57 soleil iscsid: Nop-out timedout after 15 seconds on connection 1:0 state (3). Dropping session.
May 15 01:25:57 soleil iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (1)
May 15 01:25:57 soleil iscsid: connect failed (111)
May 15 01:26:03 soleil kernel: connection1:0: iscsi: detected conn error (1011)
May 15 01:26:03 soleil iscsid: connection1:0 is operational after recovery (42 attempts)
May 15 01:26:06 soleil kernel: iscsi: host reset succeeded
Wahrscheinlich der von Octave beschriebene Bug.

bjo
14.05.08, 20:45
Zitat eines Nutzers auf der ML:

J'ai réinstallé le premier cette nuit : nickel. Opération rapide
comme quand on le lance sur un dédié, rien à voir avec les réinstall
du début de RPS.
"Schnelle Operation wie wenn er einen Dedizierten abhängt, nichts zu verlgleichen mit der Anfangszeit des RPS." (Übersetzung ohne Gewähr)

whyte
14.05.08, 20:23
Achso, klar.
Das hatte ich auch schon angefragt.
Ich vermute, dass es hierzu einen Kernelupdate geben wird.
Aber mehr wurde mir auch nicht gesagt ... na mal abwarten

bjo
14.05.08, 20:10
Sorry, ich bezog mich auf
ISCSI v2 ist für Neubestellungen und -installationen aktiviert. Für alle anderen werden wir in 3-4 Wochen sehen, wie wir das machen.

whyte
14.05.08, 20:07
Zitat Zitat von bjo
Nun stellt sich die Frage: Neu installieren oder warten? *grübel*
Auf was warten ...

So wie ich das verstanden habe, wir einem ein Backup zur Verfügung gestellt, aber nicht aufgespielt ... oder ?

bjo
14.05.08, 16:34
Nun stellt sich die Frage: Neu installieren oder warten? *grübel*

whyte
14.05.08, 16:03
naja, wenn man die SAN mit Hirsekernen füttert, kann ja nix werden ...

aber ich kann vermelden, jetzt nach 4-5 Tagen laufen beide RPS zum ersten mal wieder 24 Stunden durch - das einzige was ich geändert habe, ich habe von Netboot ein HD Kernel umgestellt.

Felix
14.05.08, 16:01
"ca plante" bedeutet eigentlich "Es pflanzt", aber auch "es hängt sich auf", "es stürzt ab", "es freezt" (ganz Neudeutsch).
Wundert mich also nicht daß babelfish und Konsorten solche Doppeldeutigkeiten nicht fachgerecht erkennen.
Aber wieso aus "Harakiri-Kernel" "Hirsekernel" wird wüßte ich auch gerne :-)

Wie auch immer, der Text ist nun auf Deutsch

miro912
14.05.08, 13:00
Zitat Zitat von pendulum
Das nenne ich mal einen grünen Provider!
Da hätte ich doch gerne ein Foto

pendulum
14.05.08, 12:49
... PflanzeniSCSI ... Hirsekernel ... target Pflanze
Das nenne ich mal einen grünen Provider!

miro912
14.05.08, 12:38
Zitat Zitat von whyte
also wirds wohl doch eine Backup-Funktion geben, finde ich toll ...
Jo, verstehe ich auch so, freu

whyte
14.05.08, 09:20
also wirds wohl doch eine Backup-Funktion geben, finde ich toll ...

miro912
14.05.08, 07:40
Naja, eine Babbelfish Übersetzung ist auch nicht das ware:

Guten Tag, Morgen Abend werden die Operationen auf RPS 197 beendet. Man geht die laufenden Projekte wieder aufzunehmen: - RPS 2 (wir haben 100 RPS 2, die pingent, um zu beginnen) wir müssen das Umkippen von RPS 1 gegen RPS 2 beenden dann wird man den Auftrag von RPS 2 erlauben. In es zu managen, du Aufträge ein RPS 2 dann sagst du " ich will von RPS1 umkippen gegen RPS2". und c' in 3 Minuten gemacht wird. Das Umkippen nur in v2. - l' iSCSI v2 ist für die neuen Kunden in Kraft und Wiedereinrichtungen. Für die anderen wird man das in 3-4 Wochen sehen. - das NFS ist bereit. man sagt nächste Woche? man braucht qu' man beenden Sie die Einführung von snap ab zu managen - wir haben Regel das mac-Problem auf filers - er bleibt ein Problem auf dem iSCSItarget unter Solaris. Er hat dort ein Bug, das dafür sorgt, dass das l'target; PflanzeniSCSI. Vom Hieb schneidet sich die Mitteilung zwischen dem SAN und dem iSCSIProxy, die iSCSIhosts stellen und machen sich ein harakiri fest. Dies vermeidet den übergang in RO von RPS. Wir gehen: - repatcher das kernel des iSCSIProxys, um sleep zu stellen an place de Hirsekernel und etwas sauber es zu machen - wir haben einen Bug im l'target gefunden; iSCSI, das war verbessert in der letzten d'version; opensolaris. Man wird verlangen an SUN backporter das Patch im solaris (wie sie l' haben Tatsache für das NFS). c' ist auch wahrscheinlich auf die Tatsache zurückzuführen, dass ZFS benutzen Sie ganzes RAM, von (zu spinnen sogar mit 64Go von RAM er nimmt 80% von RAM) und manchmal l' iSCSI hat Bedürfnisse d' ein Hieb und sehr schnell viel RAM. Die Befreiung ist langsam und das target Pflanze. Das target startet automatisch in 3-4 Wochen neu, aber c' ist ausreichend, um das Proxy zu pflanzen. - Man arbeitet auf dem persönlichen l'backup; iSCSI v2. das Ziel ist " in es zu klicken zu managen, um das now"backup zu haben; und/oder " die Backups an solchem Tag des semaine" zu programmieren;. Man behält 2 Backup in allem. all das zugänglich durch das ftp. mehr qu' zu kodieren. Freundschaftlich Oktave

oles@ovh.net
14.05.08, 00:24
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