Lokal entwickeln, auf Livesystem testen?

[Marius Sina]

Liebes Forum,

suche gerade nach der besten Lösung für folgendes Problem:

Wir entwickeln ein komplexes aber klassisches LAMP-System mit hohen Skalierungsanforderungen, hunderten von Datenbanktabellen und einer riesigen Datenbasis (nein, wir sind nicht Facebook ;)). Unsere Datenbasis haben wir auf viele DB-Server verteilt (horizontale + vertikale Partitionierung der DB). Unsere Webserver skalieren horizontal, jeder Webserver hält eine Kopie der Datenbasis.

In unserem Büro ist der Aufbau folgendermaßen:

• die Programmierer verwenden Linux, Mac, Windows und mounten dabei ihr persönliches Entwicklungs-Verzeichnis (/www/developers/marius_sina) auf dem
• zentralen Entwicklungsserver, der wiederum Datenbankanfragen weiterleitet an
• unseren internen Entwicklungs-Datenbankserver der alle Datenbanken aufnimmt

Soweit, so gut, aber:

Leider kämpfen wir sehr damit, dass die interne Datenbank kaum Testdaten enthält, um gründlich auf Bugs und Performanz zu testen, bevor man ins SVN committed. Die Livedatenbank oder auch nur Teile davon ins Büro zu kopieren ist nicht möglich bzw. würde durch viele Dateninkonsistenzen erkauft.

Erstes Szenario: um ein einigermaßen realistisches Tesumfeld zu erhalten, kam im Team die Idee auf, die DB-Instanzen der verteilten Datenbasis per Replikation auf einem zentralen, im Rechenzentrum gehosteten Datenbankserver (der nicht in die Lastverteilung eingebunden ist) zu aggregieren. Nun könnte man also ohne Risiko für die Livedaten Queries auf diese Datenbasis im Rechenzentrum absetzen, von unserem Entwicklungsserver im Büro aus.

KO-Kriterium dafür ist aber der Roundtrip vom Büro ins RZ und zurück, das funktioniert also nicht.

Zweites Szenario: wir stellen unseren Entwicklungsserver aus dem Büro raus in das Rechenzentrum und mounten dann von draussen ins Büro hinein, arbeiten weiter mit Eclipse und Co., nur dass die Dateien physikalisch im Rechenzentrum gespeichert werden.

Aber auch das scheidet IMHO aus, aus ähnlichen Gründen wie Szenario 1. Beispielsweise würde eine globale Textsuche über den Quellcode quälend langsam sein.

Vielleicht hat irgendwer Anregungen für uns?

Danke tausendfach im Vorraus!
Marius

[hotti]

hi,

Leider kämpfen wir sehr damit, dass die interne Datenbank kaum Testdaten enthält, um gründlich auf Bugs und Performanz zu testen,

Vielleicht hat irgendwer Anregungen für uns?

Eine Test-Datenbank hat genau dieselbe Struktur, dieselbe Engine, dieselbe Version und zum Testen von Anwendungen dieselben Daten wie die Produktiv-Datenbank, läuft auf derselben Plattform usw.... wo ist denn jetzt die Frage?

Inwieweit Du mit Deinem Testsystem an die Realität rankommst, musst Du mit Deinem Cheffe klären ;-)

Hotte

[Alexander (HH)]

Moin Moin!

Leider kämpfen wir sehr damit, dass die interne Datenbank kaum Testdaten enthält, um gründlich auf Bugs

DB kopieren ...

und Performanz zu testen

... auf alte Maschinen, bei denen Performance-Probleme schon mit weniger Last auftreten

Die Livedatenbank oder auch nur Teile davon ins Büro zu kopieren ist nicht möglich bzw. würde durch viele Dateninkonsistenzen erkauft.

Was ist das für ein Quatsch? Wenn Du keine konsistente Kopie der DB anfertigen kannst, hast Du erstens ein riesiges Design-Problem und zweitens kein brauchbares Backup.

Wenn Du ein brauchbares Backup hast, kannst Du es auf ein vergleichbares System vernetzter Rechner im Büro einspielen und hast dann konsistente Daten.

Aber auch das scheidet IMHO aus, aus ähnlichen Gründen wie Szenario 1. Beispielsweise würde eine globale Textsuche über den Quellcode quälend langsam sein.

Internet-Anbindung im Büro deutlich verbessern, notfalls mit einer direkten Route ins RZ.

Einer meiner ehemaligen Arbeitgeber hat fast alle internen Systeme aus dem Bürogebäude rausgeschmissen und in ein RZ gestellt. Der Unterschied ist nicht feststellbar, weder bei der Bandbreite noch bei der Latenz. Man hat einfach zwei Leitungen direkt zwischen Bürogebäude und RZ gezogen bzw. angemietet. (2x ca. 600 MBit/s, soweit ich mich erinnere)

Vielleicht hat irgendwer Anregungen für uns?

* Niemals, nie, nie, nie auf dem Produktivsystem testen
* Geld ausgeben, für Backup, Anbindung, Test- und Staging-Systeme
* Backup funktionsfähig machen
* Backup in ein nachgebautes Testsystem einspielen

Tipp: Wenn man schon Geld für neue Systeme ausgibt, dann für neue Produktivrechner. Die alten Produktivrechner wandern zum Staging, die alten Staging-Rechner wandern zum Test, die alten Test-Rechner werden verschrottet oder neuen Projekten zugeführt. Wenn ihr ohne Staging arbeitet, werden entsprechend die alten Produktivrechner direkt Testrechner.

Alexander

[Marius Sina]

Hi!

DB kopieren ...

Wie gesagt, innerhalb des RZ können wir durchaus einen DB-Server hinstellen, der alle verteilten Datenbanken aggregiert. Vom RZ ins Büro kann man nicht kopieren, das sind einfach zu viele Daten.

... auf alte Maschinen, bei denen Performance-Probleme schon mit weniger Last auftreten

Es geht eher darum überhaupt ein paar Testdaten zu haben. Diese in unserer Entwicklungsumgebung anzulegen wäre sehr mühsam, im RZ kriegen wir die umsonst.

Was ist das für ein Quatsch? Wenn Du keine konsistente Kopie der DB anfertigen kannst, hast Du erstens ein riesiges Design-Problem und zweitens kein brauchbares Backup.

Das ist kein Quatsch. Wenn Du in den Hochperformanzbereich gehst, ist erstens Denormalisierung angesagt (vergiss Deine DB-Vorlesungen), zweitens ist die Schwierigkeit, auf die ich eigentlich hinaus wollte folgende: man kann nur sehr schwer und mit dem Risiko von Dateninkonstistenzen ein kleines Subset der Daten extrahieren. Nochmal zur Erinnerung: Wir haben nicht eine Datenbank, sondern dutzende davon, jeweils mit vielen dutzenden Datenbanktabellen, insgesamt viele GB an Datenbestand. Teilweise sind sogar einzelne Tabellen auf viele Server partitioniert, anders ist die Last nicht zu managen.

Wenn Du ein brauchbares Backup hast, kannst Du es auf ein vergleichbares System vernetzter Rechner im Büro einspielen und hast dann konsistente Daten.

In meiner Anfrage habe ich bewusst einiges an Komplexität verschwiegen, wir arbeiten mit Echtzeit-Daten, eine reine Kopie macht keinen Sinn.

Internet-Anbindung im Büro deutlich verbessern, notfalls mit einer direkten Route ins RZ.

Ich denke das ist der einzige gangbare Weg für uns.

* Niemals, nie, nie, nie auf dem Produktivsystem testen

Nein, machen wir nicht.

* Geld ausgeben, für Backup, Anbindung, Test- und Staging-Systeme

Yo :)

Danke Alexander, für die ausführliche Antwort!
Marius

[dedlfix]

echo $begrüßung;

KO-Kriterium dafür ist aber der Roundtrip vom Büro ins RZ und zurück, das funktioniert also nicht.

Wenn der Roundtrip ins Rechenzentrum zu lange dauert, ist entweder das Netz eine Bremse, das man mal untersuchen kann oder die Abfrage ineffektiv.

Beispiel MySQL: Normalerweise fällt das nicht auf, aber wenn das DBMS in Asien steht und der Webserver in Europa merkt man die drei(!) Roundtrips allein beim Verbindungsaufbau deutlich. (Sind vielleicht nicht immer drei, aber ich beobachtete so viele im Zusammenhang mit MyODBC.)

Ineffektive Abfragen zu optimieren bringt letztlich nicht nur im Testbetrieb etwas sondern auch für den Produktivbetrieb.

Zweites Szenario: wir stellen unseren Entwicklungsserver aus dem Büro raus in das Rechenzentrum und mounten dann von draussen ins Büro hinein, arbeiten weiter mit Eclipse und Co., nur dass die Dateien physikalisch im Rechenzentrum gespeichert werden.

Gleiches Prinzip nur andersrum. Solange ihr nicht die Laufzeit minimiert, werdet ihr nicht glücklich. Weg verringern, Durchsatz erhöhen oder Datenmenge verringern wären die möglichen Wege.

echo "$verabschiedung $name";