KatiH schrieb am 25. Oktober 2013 17:26
> cd schrieb am 25. Oktober 2013 16:42
> > Joachim Durchholz schrieb am 25. Oktober 2013 13:24
> > >
> > > Das wär mal ein Ansatz.
> > > Ich möcht allerdings ungern irgendwelchen Oracle-Bedingungen
> > > zustimmen. Ich hab da ein bisschen Sorge, dass Oracle anfängt,
> > > Maulkörbe zu verteilen, wenn ich da gar zu deftig vom Leder ziehe.
> >
> > Spannend wird es, wenn du auch Patches laden musst - aber für's
> > Nachschauen würde ich mir da jetzt keine grauen Haare wachsen lassen,
> > solange du nicht auf die Idee kommst, die vollständigen KB-Einträge
> > zu veröffentlichen. Schliesslich muss der Kunde ja auch einen
> > Support-Vertrag abschliessen, also von daher ...
>
> Mir ist kein Fall bekannt, dass Oracle die Rechtsabteilung auf solche
> "Leaks" gehetzt hat. Das einzige in die Richtung, von dem ich gehört
> habe, waren Oracle-Mitarbeiter, die ihrem Management etwas zu
> freizügig gebloggt haben. Und die wurden nur gebeten sich etwas
> zurück gehalten und sind auch heute noch bei dem Verein.
Ich habe dafür jetzt auch nicht extra recherchiert, zumindest auf OTN
gab es den einen oder anderen Hinweis anderer Foren-Teilnehmer wenn
jemand mal einen Support-Eintrag mit copy/paste veröffentlich hat -
und es muss ja nicht immer gleich eine Klage sein, vielleicht gibt's
für so was auch erst mal nur eine Ermahnung? Ich wollte nur darauf
hinweisen, dass man keine schlafenden Hunde wecken sollte.
> > Das Problem hat u.a. auch ein ehemaliger Arbeitgeber von mir. Der
> > bietet zwar Wartungsverträge für seine Lösungen an, hat aber
> > mittlerweile kein Personal mit dem Knowhow - jetzt muss er die halt
> > zukaufen.
>
> Dumm gelaufen.
Eher Geiz und mangelnde Voraussicht. Ich fand es schade, da ich mein
Wissen gerne weitergebe und ich mich solche Aufgabenstellungen
interessieren - aber das gibt es halt nicht für lau, zumindest von
mir.
> > Mittlerweile stehe ich HW-RAID Controllern kritisch gegenüber, auch
> > wenn sie ihren Nutzen haben.
>
> Ich mag ja Dateisysteme wie ZFS: unter anderem wegen der Checksummen,
> durch die man sofort mitbekommen, wenn Daten nicht mehr konsistent
> sind.
ZFS-Storage ist nett - wobei es mittlerweile auch den einen oder
anderen Erfahrungsbericht zu BTRFS gibt, aber das dauert wohl noch
etwas, bis sich ja jemand mit Produktionsdaten drübertraut.
> Im Oracle-Umfeld wäre das dann wahrscheinlich ASM.
Block-Storage ist auch ok. Lokaler Storage ist aber noch nicht tot,
gerade bei SSDs stellt sich mittlerweile die Frage, ob man durch
NAS/SAN hier nicht wieder Leistung verschenkt, selbst mit 10 GbE oder
InfinitBand.
> Wenn natürlich das Storage-Backend Mist baut, hilft das natürlich
> nichts. Da ist dann auch egal, ob das ein Selbstbau-NAS oder ein
> dicker EMC-Turm ist.
Kaputt ist kaputt. In einem anderen Problemfall vor 2-3 Jahren lagen
nicht nur die DB-Files auf so einem Storage sondern auch die Backups.
Yay!
> > Auch eine Möglichkeit, aber damit trittst du dir wieder
> > entsprechenden Verwaltungsaufwand ein, mal ganz abgesehen davon, dass
> > sicherzustellen ist, dass beide Maschinen den gleichen Datenbestand
> > haben. Wenn man sich natürlich mehr in Richtung Data Guard/Hot
> > Standby oder simplen log shipping bewegt, wäre deine Lösung
> > vermutlich die günstigere.
>
> Ich misstraue solchen Lösungen, DRBD hast du ja weiter unten
> angesprochen.
Jede Lösung hat ihre Stärken/Schwächen - ich kann mir DRBD durchaus
für bestimmte Anwendungsbereiche vorstellen, aber da müssen dann auch
die Rahmenbedingungen passen.
> Das ist zwar unter Linux recht beliebt, aber der
> Gedanke, dass das doch nicht in allen Situationen wie lokales Storage
> reagieren kann, lässt mich schlecht schlafen. Dann lieber
> Replikationslösungen wie Data Guard.
Ohne entsprechende (Last-)Tests würde ich das auch nicht einsetzen
wollen, aber mittlerweile ist das Zeug ordentlich abgehangen. Wenn
genug Geld da ist, spricht auch nichts gegen DataGuard und andere
Lösungen.
> > s.o. RAC braucht nunmal eine zentrale Datenhaltung, auch wenn man das
> > z.B. mit DRBD unter Linux mit local storage hinbekommen könnte. Es
> > geht auch darum, was von Oracle zertifiziert ist, sonst läuft man
> > hinterher beim Support wieder in Probleme. Nicht umsonst verkaufen
> > sich NetApp & Co. in dem Bereich wie geschnittenes Brot.
>
> Die Sache mit der Zertifizierung kommt da noch hinzu.
Schliesslich möchte man ja auch noch Support vom Hersteller.
cd
> cd schrieb am 25. Oktober 2013 16:42
> > Joachim Durchholz schrieb am 25. Oktober 2013 13:24
> > >
> > > Das wär mal ein Ansatz.
> > > Ich möcht allerdings ungern irgendwelchen Oracle-Bedingungen
> > > zustimmen. Ich hab da ein bisschen Sorge, dass Oracle anfängt,
> > > Maulkörbe zu verteilen, wenn ich da gar zu deftig vom Leder ziehe.
> >
> > Spannend wird es, wenn du auch Patches laden musst - aber für's
> > Nachschauen würde ich mir da jetzt keine grauen Haare wachsen lassen,
> > solange du nicht auf die Idee kommst, die vollständigen KB-Einträge
> > zu veröffentlichen. Schliesslich muss der Kunde ja auch einen
> > Support-Vertrag abschliessen, also von daher ...
>
> Mir ist kein Fall bekannt, dass Oracle die Rechtsabteilung auf solche
> "Leaks" gehetzt hat. Das einzige in die Richtung, von dem ich gehört
> habe, waren Oracle-Mitarbeiter, die ihrem Management etwas zu
> freizügig gebloggt haben. Und die wurden nur gebeten sich etwas
> zurück gehalten und sind auch heute noch bei dem Verein.
Ich habe dafür jetzt auch nicht extra recherchiert, zumindest auf OTN
gab es den einen oder anderen Hinweis anderer Foren-Teilnehmer wenn
jemand mal einen Support-Eintrag mit copy/paste veröffentlich hat -
und es muss ja nicht immer gleich eine Klage sein, vielleicht gibt's
für so was auch erst mal nur eine Ermahnung? Ich wollte nur darauf
hinweisen, dass man keine schlafenden Hunde wecken sollte.
> > Das Problem hat u.a. auch ein ehemaliger Arbeitgeber von mir. Der
> > bietet zwar Wartungsverträge für seine Lösungen an, hat aber
> > mittlerweile kein Personal mit dem Knowhow - jetzt muss er die halt
> > zukaufen.
>
> Dumm gelaufen.
Eher Geiz und mangelnde Voraussicht. Ich fand es schade, da ich mein
Wissen gerne weitergebe und ich mich solche Aufgabenstellungen
interessieren - aber das gibt es halt nicht für lau, zumindest von
mir.
> > Mittlerweile stehe ich HW-RAID Controllern kritisch gegenüber, auch
> > wenn sie ihren Nutzen haben.
>
> Ich mag ja Dateisysteme wie ZFS: unter anderem wegen der Checksummen,
> durch die man sofort mitbekommen, wenn Daten nicht mehr konsistent
> sind.
ZFS-Storage ist nett - wobei es mittlerweile auch den einen oder
anderen Erfahrungsbericht zu BTRFS gibt, aber das dauert wohl noch
etwas, bis sich ja jemand mit Produktionsdaten drübertraut.
> Im Oracle-Umfeld wäre das dann wahrscheinlich ASM.
Block-Storage ist auch ok. Lokaler Storage ist aber noch nicht tot,
gerade bei SSDs stellt sich mittlerweile die Frage, ob man durch
NAS/SAN hier nicht wieder Leistung verschenkt, selbst mit 10 GbE oder
InfinitBand.
> Wenn natürlich das Storage-Backend Mist baut, hilft das natürlich
> nichts. Da ist dann auch egal, ob das ein Selbstbau-NAS oder ein
> dicker EMC-Turm ist.
Kaputt ist kaputt. In einem anderen Problemfall vor 2-3 Jahren lagen
nicht nur die DB-Files auf so einem Storage sondern auch die Backups.
Yay!
> > Auch eine Möglichkeit, aber damit trittst du dir wieder
> > entsprechenden Verwaltungsaufwand ein, mal ganz abgesehen davon, dass
> > sicherzustellen ist, dass beide Maschinen den gleichen Datenbestand
> > haben. Wenn man sich natürlich mehr in Richtung Data Guard/Hot
> > Standby oder simplen log shipping bewegt, wäre deine Lösung
> > vermutlich die günstigere.
>
> Ich misstraue solchen Lösungen, DRBD hast du ja weiter unten
> angesprochen.
Jede Lösung hat ihre Stärken/Schwächen - ich kann mir DRBD durchaus
für bestimmte Anwendungsbereiche vorstellen, aber da müssen dann auch
die Rahmenbedingungen passen.
> Das ist zwar unter Linux recht beliebt, aber der
> Gedanke, dass das doch nicht in allen Situationen wie lokales Storage
> reagieren kann, lässt mich schlecht schlafen. Dann lieber
> Replikationslösungen wie Data Guard.
Ohne entsprechende (Last-)Tests würde ich das auch nicht einsetzen
wollen, aber mittlerweile ist das Zeug ordentlich abgehangen. Wenn
genug Geld da ist, spricht auch nichts gegen DataGuard und andere
Lösungen.
> > s.o. RAC braucht nunmal eine zentrale Datenhaltung, auch wenn man das
> > z.B. mit DRBD unter Linux mit local storage hinbekommen könnte. Es
> > geht auch darum, was von Oracle zertifiziert ist, sonst läuft man
> > hinterher beim Support wieder in Probleme. Nicht umsonst verkaufen
> > sich NetApp & Co. in dem Bereich wie geschnittenes Brot.
>
> Die Sache mit der Zertifizierung kommt da noch hinzu.
Schliesslich möchte man ja auch noch Support vom Hersteller.
cd