hallo, Torsten Foertsch wrote:
Wenn ich schon 2 gleiche Platten drin habe und die für RAID konfigurieren will, dann macht es auch Sinn Swapspace auf das RAID zu legen, egal ob Workstation oder Server. Für das RAID muß ich nämlich die beiden Platten gleich partitionieren. Wenn nun alles außer Swap "geraided" ist, habe ich 2 gleich große aber doch im Vergleich recht kleine Partitionen übrig. Warum dann also nicht Swap auf eine RAID Partition legen?
hier wird nur über platzver(sch)wendung gesprochen. wie sieht es mit der performance aus? ist ein raid1 nich eher langsamer? ok, swap wird ehh nur in ausnahmefällen benuzt, somit spielt dies keine rolle? -- thomas
Das hat zudem den Vorteil, daß der Rechner weiterläuft, wenn eine Platte ausfällt und auch normal heruntergefahren werden kann. Wenn nämlich gerade die Platte mit Swap drauf stirbt, stürzt Dein Linux mit Sicherheit ab. Das hat evtl. unangenehme Folgen für gerade gemountete Filesysteme auch auf RAID-Platten.
Fazit: wenn schon RAID, dann richtig, inkl. Swap. Alles andere hat keinen wirklichen Sinn.
Torsten
Thomas Fankhauser wrote:
hallo,
Torsten Foertsch wrote:
Wenn ich schon 2 gleiche Platten drin habe und die für RAID konfigurieren will, dann macht es auch Sinn Swapspace auf das RAID zu legen, egal ob Workstation oder Server. Für das RAID muß ich nämlich die beiden Platten gleich partitionieren. Wenn nun alles außer Swap "geraided" ist, habe ich 2 gleich große aber doch im Vergleich recht kleine Partitionen übrig. Warum dann also nicht Swap auf eine RAID Partition legen?
Wenn der größte Teil der Platte keine sicherungsrelevanten Daten enthält, dann macht es Sinn, nur ein relativ kleines RAID1 anzulegen und den Rest halt ohne RAID zu verwenden. Ansonsten sollten beide Platten komplett als RAID1 konfiguriert werden, und dann kann man auch gleich ein Hardware-RAID nehmen, wenn so viele Daten relevant sind.
hier wird nur über platzver(sch)wendung gesprochen. wie sieht es mit der performance aus? ist ein raid1 nich eher langsamer? ok, swap wird ehh nur in ausnahmefällen benuzt, somit spielt dies keine rolle?
In einem halbwegs modernen System sollte die Performance von einem RAID1 mit zwei Platten ähnlich sein, als wäre nur eine Platte ohne RAID eingebaut. Da mir vor einiger Zeit eine Platte in meinem System abgeraucht war, hatte ich bei meinem neuen PC direkt ein Hardware-RAID angelegt, was auch mit dem Dualboot von Windows und Linux keine Probleme macht. Bei mir laufen 5 320 GB Platten im RAID5, dank des 256 MB Cache auf dem RAID-Controller ist das deutlich schneller als eine einzelne Platte. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Hallo Sandy,
Wenn der größte Teil der Platte keine sicherungsrelevanten Daten enthält, dann macht es Sinn, nur ein relativ kleines RAID1 anzulegen und den Rest halt ohne RAID zu verwenden. Ansonsten sollten beide Platten komplett als RAID1 konfiguriert werden, und dann kann man auch gleich ein Hardware-RAID nehmen, wenn so viele Daten relevant sind.
wenn ich Dir kurz widersprechen darf: Die Sicherungsrelevanz der Daten ist nicht allein ausschlaggebend für die Verwendung eines RAID-Arrays. Um's an einem Beispiel festzumachen: Die Datei /etc/hosts ist in modernen Systemen nicht sehr sicherungsrelevant, da hier in der Regel keine Veränderungen mehr vorgenommen werden. Ist diese Datei aber nicht erreichbar, gibt's wenig Freude im Netzwerk. Bei den heutigen Plattenpreisen rate ich zu RAID1 mit 1 ... n Partitionen, je Platte ein getrennter SWAP und man ist fast da.
Da mir vor einiger Zeit eine Platte in meinem System abgeraucht war, hatte ich bei meinem neuen PC direkt ein Hardware-RAID angelegt, was auch mit dem Dualboot von Windows und Linux keine Probleme macht. Bei mir laufen 5 320 GB Platten im RAID5, dank des 256 MB Cache auf dem RAID-Controller ist das deutlich schneller als eine einzelne Platte. Was für einen RAID-Controller benutzt Du?
-- So long Bernd
Bernd Glueckert wrote:
Hallo Sandy,
Wenn der größte Teil der Platte keine sicherungsrelevanten Daten enthält, dann macht es Sinn, nur ein relativ kleines RAID1 anzulegen und den Rest halt ohne RAID zu verwenden. Ansonsten sollten beide Platten komplett als RAID1 konfiguriert werden, und dann kann man auch gleich ein Hardware-RAID nehmen, wenn so viele Daten relevant sind.
wenn ich Dir kurz widersprechen darf: Die Sicherungsrelevanz der Daten ist nicht allein ausschlaggebend für die Verwendung eines RAID-Arrays.
Um's an einem Beispiel festzumachen: Die Datei /etc/hosts ist in modernen Systemen nicht sehr sicherungsrelevant, da hier in der Regel keine Veränderungen mehr vorgenommen werden.
Ist diese Datei aber nicht erreichbar, gibt's wenig Freude im Netzwerk.
So etwas macht die Datei sicherungsrelevant. Ich würde das gesamte /etc als sicherungsrelevant bezeichnen. In den Konfigurationsdateien stecken oft tagelange Test-Orgien. (^-^)
Bei den heutigen Plattenpreisen rate ich zu RAID1 mit 1 ... n Partitionen, je Platte ein getrennter SWAP und man ist fast da.
Da ich nicht mit dem Cent rechnen muss, setze ich keinen Rechner mehr ohne RAID auf. Aber wie gesagt, ich gehe da nicht von mir aus.
Da mir vor einiger Zeit eine Platte in meinem System abgeraucht war, hatte ich bei meinem neuen PC direkt ein Hardware-RAID angelegt, was auch mit dem Dualboot von Windows und Linux keine Probleme macht. Bei mir laufen 5 320 GB Platten im RAID5, dank des 256 MB Cache auf dem RAID-Controller ist das deutlich schneller als eine einzelne Platte.
Was für einen RAID-Controller benutzt Du?
Areca 1220 (PCI-Express) mit BBU Ich sehne mich nach Suse 10.3, die wird dann bestimmt Kernel 2.6.19 oder jünger haben und endlich den Areca ohne Gefummel unterstützen. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Hallo Sandy,
So etwas macht die Datei sicherungsrelevant. Ich würde das gesamte /etc als sicherungsrelevant bezeichnen. In den Konfigurationsdateien stecken oft tagelange Test-Orgien. (^-^)
ja, aber eher in /etc/postfix & Co. ... Ich habe mein /etc in ein subversion repository abgelegt - damit kann man gut auf ältere Versionen zurückgreifen.
Da ich nicht mit dem Cent rechnen muss, setze ich keinen Rechner mehr ohne RAID auf. Aber wie gesagt, ich gehe da nicht von mir aus. Wenn ich mir einen aktuellen Rechner ansehe und z.B. 'ne 300GByte-Platte nehme, dann sind es nur etwa 80 Euro für eine zweite Platte. Gemessen an dem Stress den man hat, wenn man die Kiste braucht und man sieht statt dessen ein "DriveReady SeekComplete Error", sind die 80 Öre gut angelegt. Bis so eine Workstation wieder richtig eingerichtet ist dauert es gut 1 - 2 Tage.
Ich mache es wie Du: Neue Rechner nur noch mit RAID. Server sowieso!
Areca 1220 (PCI-Express) mit BBU
Ich sehne mich nach Suse 10.3, die wird dann bestimmt Kernel 2.6.19 oder jünger haben und endlich den Areca ohne Gefummel unterstützen.
Areca - muss ich zugeben - kannte ich bisher nicht. Meine 3Ware-Controller laufen gut, aber die SATA-II-Controller kommen nur dann in Fahrt, wenn Du einen 64-Bit PCI-Bs hast. Den hat kaum ein bezahlbares Motherboard. Jetzt gibt's aber seit gestern einen SATA-II von 3Ware mit PCI-X Interface. Wenn ich so zwischen Deinen Zeilen lese, ist der Areca etwas umständlich zu installieren. Erzähl mehr darüber - und wo Du das Teil bekommen hast. Ich muss in den nächsten Monaten ein paar Mail-Server aufrüsten - und bei uns darf alles sterben, nur nicht ein Mail-Server. -- So long Bernd
Bernd Glueckert wrote:
Hallo Sandy,
So etwas macht die Datei sicherungsrelevant. Ich würde das gesamte /etc als sicherungsrelevant bezeichnen. In den Konfigurationsdateien stecken oft tagelange Test-Orgien. (^-^)
ja, aber eher in /etc/postfix & Co. ... Ich habe mein /etc in ein subversion repository abgelegt - damit kann man gut auf ältere Versionen zurückgreifen.
Das ist etwas, was ich auch noch vorhabe. Bisher habe ich mich noch nicht mit Subversion beschäftigt.
Areca 1220 (PCI-Express) mit BBU
Ich sehne mich nach Suse 10.3, die wird dann bestimmt Kernel 2.6.19 oder jünger haben und endlich den Areca ohne Gefummel unterstützen.
Areca - muss ich zugeben - kannte ich bisher nicht. Meine 3Ware-Controller laufen gut, aber die SATA-II-Controller kommen nur dann in Fahrt, wenn Du einen 64-Bit PCI-Bs hast. Den hat kaum ein bezahlbares Motherboard.
Der Areca, den ich hier habe, ist schon sehr leistungsfähig, aber nicht gerade billig. Auch die Features sind sehr breit gefächert. Meines Wissens nach ist der PCI-Express nicht über eien 64-Bit Bus gekoppelt, sondern kommuniziert direkt mit dem Chipsatz, und das halt mit der Geschweindigkeit, die der Menge der Lanes entspricht. Der Areca braucht mindestens einen 8x-Slot, um vernünftig zu laufen.
Jetzt gibt's aber seit gestern einen SATA-II von 3Ware mit PCI-X Interface.
Wenn ich so zwischen Deinen Zeilen lese, ist der Areca etwas umständlich zu installieren. Erzähl mehr darüber - und wo Du das Teil bekommen hast. Ich muss in den nächsten Monaten ein paar Mail-Server aufrüsten - und bei uns darf alles sterben, nur nicht ein Mail-Server.
Ich hatte den Controller inclusive Batterie-Backup-Einheit bei einem Vertragshändler von Starline bestellt, ich glaube bei Delta-Computer. Jedenfalls würde ich gerade wegen des nicht im Kernel mitgelieferten Treibers im Augenblick nicht einen Areca empfehlen. Das fummeln bei jedem Kernel-Update ist wirklich nicht das wahre, und das ist ja gerade das, warum man eine Distribution nimmt und nicht Linux-From-Scratch verwendet, wegen der einfachen und transparenten Software-Verwaltung (wenn sie denn funktioniert...). Mit Suse 10.3 wird das wohl anders werden. Dann kann man beruhigt Kernel-Updates machen und muss nicht jedes Update sorgfältig planen. Insgesamt ist der Controller wirklisch nett, RAID6 fast ohne Leistungseinbußen, automatische Benachrichtigungen über den Status etc per Email, übersichtliche Konfigurationsoberfläche und einiges mehr. Jedenfalls empfehle ich gerade bei einem Mailserver den Schreibcache nur einzuschalten, wenn der Controller eine BBU hat und hinter einer USV läuft. Nachdem ich mich über einige Brown-Outs bei mir zuhause geärgert hatte, sitzen auch bei mir zuhause jetzt meine Rechner hinter einer kleinen USV. Ebenso keinen Controller zu nehmen, der nicht direkt vom Kernel der Distribution unterstützt wird, sonst macht ein Kollege ein Update, startet die Kiste neu, und fängt an, nach Papa zu schreien... Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Am 08.11.06 schrieb Bernd Glueckert
Ich muss in den nächsten Monaten ein paar Mail-Server aufrüsten - und bei uns darf alles sterben, nur nicht ein Mail-Server.
Nimm LSI. Die sind sehr OSS-freundlich. http://www.vendorwatch.org/index.php?title=LSI Gruß Martin
Hi Bernd, Am Mittwoch, 8. November 2006 20:58 schrieb Bernd Glueckert: [...]
Areca 1220 (PCI-Express) mit BBU
Ich sehne mich nach Suse 10.3, die wird dann bestimmt Kernel 2.6.19 oder jünger haben und endlich den Areca ohne Gefummel unterstützen.
Areca - muss ich zugeben - kannte ich bisher nicht. Meine 3Ware-Controller laufen gut, aber die SATA-II-Controller kommen nur dann in Fahrt, wenn Du einen 64-Bit PCI-Bs hast. Den hat kaum ein bezahlbares Motherboard.
Jetzt gibt's aber seit gestern einen SATA-II von 3Ware mit PCI-X Interface.
welche 3Ware-Controller hast Du im Einsatz? Auch welche für PCI-E? Sind die ernsthaft langsamer als PCI-X oder PCI-64? Im ct-Test hatten die vor einiger Zeit recht super abgeschnitten. Zusammen mit Areca die schnellsten SATA-Raid-Controller. Grüße Philipp -- Q: Why did the germ cross the microscope? A: To get to the other slide. ###signature by fortune###
Philipp Zacharias wrote:
Areca - muss ich zugeben - kannte ich bisher nicht. Meine 3Ware-Controller laufen gut, aber die SATA-II-Controller kommen nur dann in Fahrt, wenn Du einen 64-Bit PCI-Bs hast. Den hat kaum ein bezahlbares Motherboard.
Jetzt gibt's aber seit gestern einen SATA-II von 3Ware mit PCI-X Interface.
welche 3Ware-Controller hast Du im Einsatz? Auch welche für PCI-E? Sind die ernsthaft langsamer als PCI-X oder PCI-64? Im ct-Test hatten die vor einiger Zeit recht super abgeschnitten. Zusammen mit Areca die schnellsten SATA-Raid-Controller.
Nein, PCIe ist definitiv nicht langsamer, eher schneller. Die Schnittstelle PCIe ist ein vielfaches schneller als PCI-64/PCI-X. Ich erwarte, dass PCI-X ein Nischendasein führen wird, während PCIe hoffentlich zunehmend auch in Servern integriert wird auf Kosten von PCI-X. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Hi Sandy, Am Donnerstag, 9. November 2006 12:51 schrieb Sandy Drobic:
Philipp Zacharias wrote:
Areca - muss ich zugeben - kannte ich bisher nicht. Meine 3Ware-Controller laufen gut, aber die SATA-II-Controller kommen nur dann in Fahrt, wenn Du einen 64-Bit PCI-Bs hast. Den hat kaum ein bezahlbares Motherboard.
Jetzt gibt's aber seit gestern einen SATA-II von 3Ware mit PCI-X Interface.
welche 3Ware-Controller hast Du im Einsatz? Auch welche für PCI-E? Sind die ernsthaft langsamer als PCI-X oder PCI-64? Im ct-Test hatten die vor einiger Zeit recht super abgeschnitten. Zusammen mit Areca die schnellsten SATA-Raid-Controller.
Nein, PCIe ist definitiv nicht langsamer, eher schneller. Die Schnittstelle PCIe ist ein vielfaches schneller als PCI-64/PCI-X. Ich erwarte, dass PCI-X ein Nischendasein führen wird, während PCIe hoffentlich zunehmend auch in Servern integriert wird auf Kosten von PCI-X.
dass PCIe prinzipiell schneller ist als PCI-64 und PCI-X (ganz zu schweigen vom alten Standard-PCI) ist mir schon klar. Bernd hat nur leider nicht geschrieben, welchen Controller er im Einsatz hat. Unabhängig von der Schnittstelle könnte es ja dennoch sein, dass der 3ware PCIe-Controller langsamer ist als der PCI-X (unwahrscheinlich, aber möglich). Daher hab ich nochmal nachgefragt. Grüße Philipp -- Beware of a tall black man with one blond shoe. ###signature by fortune###
Philipp Zacharias wrote:
Hi Sandy,
Am Donnerstag, 9. November 2006 12:51 schrieb Sandy Drobic:
Nein, PCIe ist definitiv nicht langsamer, eher schneller. Die Schnittstelle PCIe ist ein vielfaches schneller als PCI-64/PCI-X. Ich erwarte, dass PCI-X ein Nischendasein führen wird, während PCIe hoffentlich zunehmend auch in Servern integriert wird auf Kosten von PCI-X.
dass PCIe prinzipiell schneller ist als PCI-64 und PCI-X (ganz zu schweigen vom alten Standard-PCI) ist mir schon klar. Bernd hat nur leider nicht geschrieben, welchen Controller er im Einsatz hat. Unabhängig von der Schnittstelle könnte es ja dennoch sein, dass der 3ware PCIe-Controller langsamer ist als der PCI-X (unwahrscheinlich, aber möglich). Daher hab ich nochmal nachgefragt.
Da hast du schon recht, die Schnittstelle allein macht nicht die Geschwindigkeit des Controllers aus. Insgesamt sind die Fortschritte im RAID-Bereich im Augenblick derart rasant, dass 12 Monate alte Hardware heute schon als hoffnungslos veraltet gilt. Deshalb ist es nicht ganz fair, vorhandene Hardware mit neuer Hardware zu vergleichen. Das galt für den Serverbereich sonst nicht in dieser Härte. Aber inzwischen haben sich auch im Serverbereich die Zyklen sehr beschleunigt. Deshalb plane ich nicht mehr für mehr als zwei Jahre hinaus. Ausnahmen sind Schnittstellen- und Medien-Entscheidungen, etwa für Backup. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Hallo Sandy, hallo Philipp, ich habe noch zwei Controller aus der 7500er-Serie im Einsatz, die ein normale PCI-32 und PCI-64 bedienen. Gekauft Anfang 2005. Verglichen mit den modernen RAIDs wie 3Ware 9500 bzw. 9600 sind das etwa 3 Eiszeiten davor. Ich kann Sandy's Aussage nur unterstreichen: Im Moment ist die Entwicklung bei RAID-Controllern wirklich rasant. Und deswegen wird bei nächster Gelegenheit in unserem Domino-Server ein 9650 eingesetzt. Wichtig bei einem RAID-System ist nämlich auch die Übermittlung von Statusinformationen, ob z.B. eine Platte schon lahmt. Und da war die 7500er Serie eher schlecht bestückt. Neuere 9500er RAIDs haben das SMART-Interface implementiert und man kann mit Linux-Bord-Mitteln darauf zugreifen. -- So long Bernd
Bernd Glueckert wrote:
Hallo Sandy, hallo Philipp,
ich habe noch zwei Controller aus der 7500er-Serie im Einsatz, die ein normale PCI-32 und PCI-64 bedienen. Gekauft Anfang 2005.
Ein normaler PCI-32-Bus ist völlig überfordert mit der Leistung der modernen Platten/RAID-Controller. Wenn man 5 Platten mit ca. 60MB/s in ein RAID5 kombiniert, was durchaus üblich ist, dann ist man bereits beim dreifachen der Durchsatz-Leistung eines PCI-32-Bit-Busses. Selbst ein PCI-64-Bit-Bus muss schon mit 66MHz laufen, um nicht zum Flaschenhals zu werden. Wenn 8 Platten mit 70 MB/s verwendet werden, ist auch dieser komplett erschöpft. Deshalb ist PCI-X oder PCIe heute Pflicht für RAID-Controller. Auch SCSI-320 ist inzwischen nicht mehr in der Lage, ein RAID mit mehr als 4 Platten mit voller Leistung zu verwenden, und eine höhere Spezifikation scheint nicht in Sicht zu sein. Der Trend schein in Richtung SAS zu gehen.
Verglichen mit den modernen RAIDs wie 3Ware 9500 bzw. 9600 sind das etwa 3 Eiszeiten davor. Ich kann Sandy's Aussage nur unterstreichen: Im Moment ist die Entwicklung bei RAID-Controllern wirklich rasant.
Und deswegen wird bei nächster Gelegenheit in unserem Domino-Server ein 9650 eingesetzt.
Wenn ich sehe, wie unsere Dominoserver auf der Platte am Sägen sind, dann kann ich nur dazu raten, einen Controller mit viel Cache zu nehmen und am besten mit Batteriepufferung. Man kann zwar auch den Schreibcache manuell aktivieren, aber es gibt gute Gründe, warum dieser ohne BBU nicht aktiviert wird.
Wichtig bei einem RAID-System ist nämlich auch die Übermittlung von Statusinformationen, ob z.B. eine Platte schon lahmt. Und da war die 7500er Serie eher schlecht bestückt. Neuere 9500er RAIDs haben das SMART-Interface implementiert und man kann mit Linux-Bord-Mitteln darauf
Auch das kann ich nur unterschreiben. Wichtig ist nicht nur gute Leistung, sondern auch Robustheit, gute Handhabung und Transparenz bei der Verwaltung. Ich habe wirklich keine Lust, im Serverraum täglich mich auf die Server einzuloggen und den Status des Raids zu überprüfen. Das sollen die gefälligst von sich aus melden, wenn etwas nicht stimmt. (^-^) Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Hallo Sandy,
Wenn ich sehe, wie unsere Dominoserver auf der Platte am Sägen sind, dann kann ich nur dazu raten, einen Controller mit viel Cache zu nehmen und am besten mit Batteriepufferung.
dass Du Postfix ganz gut kennst, wusste ich ja, aber auch Domino: Welche Version auf welchen Servertypen läuft bei Dir? Wir haben Dominos von 6.5.4 bis 7.0.2 auf SuSE 9.1, SuSE 10.0 und Gentoo - und bis auf den alten 9.1er-Server läufts auch ganz gut. Wenn ich so sehe, was Domino an Datenmengen umsetzt, bleibt nur der Griff zu sehr viel RAM und schnellen Platteninterfaces. Wer einmal bei uns in der Firma die Vorzüge von replizierten Datenbanken kennengelernt hat, der wirft alle seine Dokumente in die Document Libraries. Allein in den letzten 12 Monaten hat sich unser Datenvolumen verdreifacht - bis März wird es nochmal Faktor 8 - 10 werden. Die Leute haben Blut geleckt. Deswegen muss jetzt auch ein neues Speichermedium her.
Auch das kann ich nur unterschreiben. Wichtig ist nicht nur gute Leistung, sondern auch Robustheit, gute Handhabung und Transparenz bei der Verwaltung. Ich habe wirklich keine Lust, im Serverraum täglich mich auf die Server einzuloggen und den Status des Raids zu überprüfen. Das sollen die gefälligst von sich aus melden, wenn etwas nicht stimmt. (^-^)
Was setzt Du als Server-Überwachungstool ein? Wir haben Nagios installiert und bauen jetzt sukzessive die überwachten Services aus. Das hat schon viele Crashes vorab angekündigt. Sehr empfehlenswert. -- So long Bernd
Bernd Glueckert wrote:
Hallo Sandy,
Wenn ich sehe, wie unsere Dominoserver auf der Platte am Sägen sind, dann kann ich nur dazu raten, einen Controller mit viel Cache zu nehmen und am besten mit Batteriepufferung.
dass Du Postfix ganz gut kennst, wusste ich ja, aber auch Domino: Welche Version auf welchen Servertypen läuft bei Dir?
Bei uns laufen ein 6.5.5 (Blackberry) und zwei 7.0.1, alle jedoch unter Windows. Wobei sich meine Kenntnisse jedoch auf die Administration der Server beschränkt, Anwendungsentwicklung ist nach extern ausgelagert. Ist auch gut so, ich habe genügend andere Themen, die meine Zeit beanspruchen.
Wir haben Dominos von 6.5.4 bis 7.0.2 auf SuSE 9.1, SuSE 10.0 und Gentoo - und bis auf den alten 9.1er-Server läufts auch ganz gut. Wenn ich so sehe, was Domino an Datenmengen umsetzt, bleibt nur der Griff zu sehr viel RAM und schnellen Platteninterfaces. Wer einmal bei uns in der Firma die Vorzüge von replizierten Datenbanken kennengelernt hat, der wirft alle seine Dokumente in die Document Libraries. Allein in den letzten 12 Monaten hat sich unser Datenvolumen verdreifacht - bis März wird es nochmal Faktor 8 - 10 werden. Die Leute haben Blut geleckt.
Das Phänomen kenne ich, die Datenmenge wächst rasant. Die Leute löschen keine Mails und sehen ihr Postfach als bequeme Rücklage an. Teilweise wollen die Leute einfach alles als Mail haben (selbst lokal abgelegt Sachen), damit sie bequem die Suchfunktionen nutzen können. Ehrlich gesagt macht es mir nicht viel, wie groß die Datenbanken sind, übler finde ich die Backup-Problematik, da die Datenbanken immer größer werden und entsprechend viel jeden Tag gesichert werden muss. Deshalb habe ich angefangen und auf einem Backupserver eine Replikation eingerichtet, damit ich nicht mehr den zentralen Server direkt sichern muss, sondern einen konsistenten Stand sichern kann, der über das Backupfenster konstant bleibt.
Auch das kann ich nur unterschreiben. Wichtig ist nicht nur gute Leistung, sondern auch Robustheit, gute Handhabung und Transparenz bei der Verwaltung. Ich habe wirklich keine Lust, im Serverraum täglich mich auf die Server einzuloggen und den Status des Raids zu überprüfen. Das sollen die gefälligst von sich aus melden, wenn etwas nicht stimmt. (^-^)
Was setzt Du als Server-Überwachungstool ein?
Wir haben Nagios installiert und bauen jetzt sukzessive die überwachten Services aus. Das hat schon viele Crashes vorab angekündigt. Sehr empfehlenswert.
Bisher setze ich noch einige Einzellösungen und Big Brother ein. Die meisten Server sind Fujitsu-Siemens Primergy Server, deshalb werde demnächst wohl ServerView einsetzen, um den Status zu pollen. Dummerweise ist gerade die Linux-Unterstützung nicht sehr ausgeprägt. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Hallo Sandy,
Bei uns laufen ein 6.5.5 (Blackberry) und zwei 7.0.1, alle jedoch unter Windows. Wobei sich meine Kenntnisse jedoch auf die Administration der Server beschränkt, Anwendungsentwicklung ist nach extern ausgelagert. Ist auch gut so, ich habe genügend andere Themen, die meine Zeit beanspruchen.
Wie hier. Aber bis auf einen Passthrough Server in der DMZ setzen wir auf die 7.0.1 bzw. jetzt auf die 7.0.2 auf, die alle völlig klaglos unter Linux schnurren. Und zwar sehr performant und zuverlässig! Es muss wirklich keine SLES sein.
Das Phänomen kenne ich, die Datenmenge wächst rasant. Die Leute löschen keine Mails und sehen ihr Postfach als bequeme Rücklage an. Teilweise wollen die Leute einfach alles als Mail haben (selbst lokal abgelegt Sachen), damit sie bequem die Suchfunktionen nutzen können.
Ich habe Leute mit 20.000 Mails in der Datenbank und jetzt immer mehr Leute, die Ihre gesamten Preislisten, Prospekte, Entwicklungsunterlagen etc. in die Doclibs tun - was mit mir angefangen hat. Es ist halt ein toller Vorteil, wenn ein Mitarbeiter kurz die Replikation aufruft und mit den neuesten Datenbanken beim Kunden aufschlägt. Seitdem ich VMware nutze und der Notes-Client darunter wirklich gut arbeitet, habe ich mein WIndows nur noch in einer virtuellen Maschine. Ich bin schon gespannt auf das Hannover-Release.
Ehrlich gesagt macht es mir nicht viel, wie groß die Datenbanken sind, übler finde ich die Backup-Problematik, da die Datenbanken immer größer werden und entsprechend viel jeden Tag gesichert werden muss. Deshalb habe ich angefangen und auf einem Backupserver eine Replikation eingerichtet, damit ich nicht mehr den zentralen Server direkt sichern muss, sondern einen konsistenten Stand sichern kann, der über das Backupfenster konstant bleibt. Ich habe ständig einen zweiten Domino Server laufen, der jede Minute komplett repliziert. Der wird irgendwann demnächst so konfiguriert, dass er einmal täglich die Datenbanken auf einen anderen Server / ein anderes Verzeichnis repliziert, wo dann gesichert werden kann.
-- So long Bernd
participants (6)
-
Andre Tann -
Bernd Glueckert -
Martin Schröder -
Philipp Zacharias -
Sandy Drobic -
Thomas Fankhauser