[sage] Linux LVM2: Rollback von Snapshots moeglich?

[Wolfgang Stief]

Tach zusammen!

On Tue, 29 Jul 2008 14:38:40 +0200
Benedikt Stockebrand <me at benedikt-stockebrand.de> wrote:

> > Mit Solaris und ZFS Snapshots wäre das kein besonders großes
> > Problem, es gibt ein "zfs rollback <snapshotname>".
> >
> > [...]
> >
> > Weder Oracle noch SLES stehen (leider) zur Debatte.
> 
> Aus welchem Grund ist Solaris+ZFS keine Alternative?

Die Entscheidung für die darunterliegende Architektur wurde lange vor
unserem Auftreten gefällt. Kunde ist eine große bayerische Behörde, das
konkrete Projekt ist Teil eines großen Ganzen, das irgendwann mal bei
allen entsprechenden Länderbehörden über ganz Deutschland zum Einsatz
kommt. Mal eben so hingehen und sagen "übrigens, das mit Linux ist
keine besonders gute Idee, weil..." ist also nicht drin.

So oder so wird in unserer Ausarbeitung drin stehen, dass man
alternativ Solaris mit ZFS betrachten sollte und das mit allerlei
Vorteilen im Handling und bei der Flexibilität begründen.

Wir haben bereits im ersten Meeting vorsichtig vorgefühlt, ob denn an
der Wahl des Betriebssystems noch Einfluß zu nehmen sei. Damals bekamen
wir ein ganz klares Nein. Bei der Vorstellung, einem Linux 20TB Oracle
anzuvertrauen, bekomme ich per default weiche Knie und ein flaues
Gefühl im Magen. Aber das ist eine andere Geschichte :-)

Nicht, dass Linux das nicht technisch könnte. Aber So Dinge wie
Patch- und Releasemanagement spielen halt auch eine Rolle. Anderes
Thema :-)

> Eine Lizenz kostet wenn überhaupt nur Bruchteile dessen, was man für
> das SAN offensichtlich schon bereit war auszugeben.  Und wenn man bei
> PC-Hardware bleibt, dann sind auch die Hardware-Kosten unverändert.

Du wirst aus eigener Erfahrung wissen, dass bei Behörden die Kosten nur
eine untergeordnete Rolle spielen. Auch, wenn sie öffentlich
ausschreiben und das günstigste Angebot nehmen müssen. Es gibt genügend
geschlossene Ausschreibungen da draußen :-)

Und unterschätze Oracle Lizenzkosten nicht! :-)

> Meiner Meinung nach läufst Du hier sehr stark Gefahr, eine
> offensichtlich politisch motivierte Fehlentscheidung auf technischer
> Ebene mehr schlecht als recht abzufangen.

Naja: Auftrag ist, die unterschiedlichen Möglichkeiten zu beleuchten.
Wir müssen keine Hardware, keine Software und erst recht keine fertige
Lösung verkaufen geschweige denn implementieren. Zu was sie sich am
Ende entscheiden und welche Probleme dabei zu lösen sind, kann mir im
Prinzip egal sein. Ist es mir natürlich nicht ganz, schließlich wollen
wir Folgegeschäft und deshalb ein professionelles Bild abgeben.

> Dabei wird vermutlich eine produktionsuntaugliche Krüppellösung
> rauskommen, die langfristig nur Ärger mit sich bringt. Am Ende läuft
> es sehr schnell darauf hinaus, dass man das ganze als technische
> Fehlkonzeption hinstellt und über Jahre hinweg Deiner angeblichen
> Inkompetenz die Schuld in die Schuhe schiebt.

Naja. Ich sage -- wie oben angedeutet -- ja nicht "macht das so und so
und dann rennt das". Bekanntlich führen viele Wege nach Rom, alle haben
Vor- und Nachteile. Diese Vor- und Nachteile stellen wir gegenüber und
überlassen dem Kunden dann die Entscheidung. Da das Projekt bundesweit
koordiniert wird, hat unser Kunde auch da nur begrenzt eigene
Entscheidungskompetenz. Was wiederum ganz klar politisch motivierte
Gründe hat. Darauf hat dann auch eine IT-Abteilung geschweige denn ein
externer Dienstleister keinen direkten Einfluss mehr. Wir können
bestenfalls hoffen, mittels der aufgezeigten Vor- und Nachteile die
passenden Argumentationshilfen zu liefern.

Und um den Bogen zurück zu meiner gestrigen Frage zu kriegen: Eine der
möglichen Ansätze für einen Teil der Problemstellung wäre ein Snapshot
per lokalem Volume Management. Das macht aber nur dann brauchbar Sinn,
wenn ich so einen Snapshot auch schnell zurück rollen kann und nicht
erst ein Backup auf Band ziehen und das Backup restoren muss.
Mittlerweile weiß ich, dass LVM2 kein solches rollback kennt, und damit
für die Problemstellung nicht das Mittel der Wahl ist. Der Hinweis,
dass LVM-Snapshots möglicherweise stark Performance fressen, tut sein
übriges. Wobei ich das nochmal hier im Haus nachvollziehen will.
Vermutlich wird es auf Snapshots im Storage hinauslaufen bzw. den
Hinweis, dass Solaris/ZFS das könnte. Zu Snapshots und Replikation im
Storage kamen im letzten Meeting bereits eine Menge Fragen, der Kunde
weiß also schon so halbwegs, worauf er sich einlässt.

Ich finde insgesamt, dass es ein SEHR gewagter Schritt ist, mit einer
zentralen Datenbank von BS2000/ISAM auf Linux/Oracle zu gehen.

Hmmm... die fertige Betrachtung wäre evtl auch einen Artikel in der
UpTimes wert. Bei Gelegenheit $KUNDE nach seiner Einwilligung fragen...


wolfgang

-- 
  Jabber/XMPP: stief at guug.de                http://www.guug.de/
 ---------------------------------------------------------------
  German Unix User Group @ Xing   https://www.xing.de/net/guug/
  Linux-Kongress 2008            http://www.linux-kongress.org/
  Open Solaris Developer Conference    http://www.osdevcon.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.guug.de/pipermail/sage/attachments/20080729/658b44e7/attachment.pgp