Archiv verlassen und diese Seite im Standarddesign anzeigen : Server und NAS synchronisieren
Hi,
ich arbeite als Praktikant in ner Firma und mein Vorgesetzter soll folgendes Problem lösen, hat dafür allerdings noch keine Lösung gefunden.
Der Kunde speichert seine Daten auf einem Server ab. Über Nacht wird ein Backup auf ein NAS gemacht, was allerdings viel zu lange dauert.
Daher sollen die Daten in Echtzeit synchronisiert werden.
Sprich der Anwender speichert auf dem Server und die Daten sollen sofort auf das NAS geschrieben bzw. synchronisiert werden.
Zur Umgebung kann ich z.Z. nur sagen das auf dem Server ein aktuelles Suse Enterprise läuft.
Wie lässt sich das mit welchen Programmen realisieren?
Danke und Tschö
"Echtzeit" ist immer so eine Sache...
Spontan fällt mir cron + rsync ein (es werden nur Änderungen übertragen, da gehen auch große Datenbestände recht flott zum Abgleich) - allerdings nicht in Echtzeit.
Dann gäbe es noch DRBD - in Produktivumgebungen allerdings nicht unbedingt so beliebt...
Man könnte aber auch ein logisches Raid einrichten...
hallo,
es gäb auch die möglichkeit das rsync als dämon zu starten, ob damit ein online-ablgeich möglich ist kann ich aber nicht sagen, klang zumindest für mich so in der manpage...
ansonsten über cron...
ein backup von platte auf platte... nicht sehr sinnvoll. eine festplatte ist kein backupmedium! um wieviel daten handelt es sich die gesichert werden müssen? was ist für serverhardware im einsatz und was steht an geld zur verfügung um das ganze zu lösen.
datensicherheit sollte man nicht auf die leichte schulter nehmen!
Naja, rein prinzipiell ist dagegen eigentlich nichts zu sagen - BackupDaten auf einem Raid50 mit 2x Hotspare würde ich durchaus als sicher erachten. Und es schadet ja nicht, die Dinger dort vorzuhalten um sie dann von dort aus auf ein Tape zu sichern - darüber wissen wir bisher ja nichts...
Wenn das NAS allerdings eine USB-Festplatte mit Netzwerkanschluss ist, dann hast Du Recht...
NAS Wegschmeissen und ne SAN dranhaengen und einen Mirror aufsetzen.
Das was da gerade gemacht wird ist Unfug.
Alternative: statt vom Server aufs NAS zu kopieren die NAS so einsetzen, wie die NAS eigentlich gedacht ist. Direkt auf dem Server einbinden, denn wird auch ordentlich "online" geschrieben. Zur einfachen, höhern Datensicherheit koennt ihr ja tägliche Snapshots oder so anlegen. Die NAS sollte eh als RAID laufen, je nach Anwendung, ein RAID 4,5,6,10 oder sowas.
Aber fuer das was ihr machen wollt ist eine SAN gedacht, nicht die NAS
gruss,
anniy
Hm, ist ein NAS nicht Bestandteil eines SAN?
ich glaube, wir sollten hier uns mal über die Begrifflichkeiten und was der TE darunter versteht, klarwerden...
Nein, ist es nicht.
Eine SAN ist "sozusagen" eine "externe Festplatte". nur, dass diese externe Festplatte gleich ein ganzes Storage-Netzwerk sein kenn, z.B. über Fiberchannel. Dafuer hast du eigene "Netzwerkadapter" HBA genannt, Und eigene Switches etc. Du kannst aus der SAN einzelne Slices rausmappen, die du als Block-Device in System wieder einbinden kannst.
Eine NAS ist Nix weiter als ein Server der dir Netzwerkfilesysteme zur verfügung stellt.
Natuerlich kanntest Du hinter der NAS eine SAN betreiben, aber nicht eine SAN aus lauter NAS zusammenbauen.
gruss,
anniy
Aus meiner Sicht könnten wir über den letzten Satz diskutieren... Aber lassen wir das, das geht glaube ich über den konkreten Bedarf dieses Threads hinaus...
Interessant wäre nun, wie es denn beim TE nun konkret aus sieht...
Ich schreibs doch hier hin, weil ich denke das es von zentraler Bedeutung ist, das man auch in diesem Thread weiss, was die verschiedenen Sachen eigentlich sind.
Es gibt da nichts zu diskutieren, weil es fundeamentale technische unterschiede sind.
SANs sind Speichernetzwerke und was du daraus bekommst sind Block-Devices.
Das kannst du mit NAS nicht machen. Versuch mal von einer NAS 2 Verzeichnisse zu mounten und darauf ein RAID 1 zu legen. Mit einer SAN kannst du genau das machen. Du bindest zwei Devices, NICHT Verzeichnisse, ein, lässt ein RAID drueber laufen und mountest es wie eine lokale Festplatte.
Oder ganz kurz:
SAN: Block
NAS: Filesharing
Du kannst Filesharing-Dienste nicht zu einem Block-Gerät zusammenfassen aber umgekehrt kann ein Gerät das Filesharing anbietet Blockgeräte einbinden.
http://de.wikipedia.org/wiki/Storage_Area_Network
http://www.speicherguide.de/magazin/san.asp?theID=455
gruss,
anniy
ok - schon klar, da hatte ich dann glaube ich etwas falsch interpretiert oder dank der etwas kurzen Nacht nicht ganz durchdacht* (um mal WagTheDog zu zitieren...)
* anders gesagt: Ich brauche Feierabend...
mal ne frage die dann schon fast off-topic ist.
wie würdest du den iscsi dann einstufen? eher san oder doch nas?
iscsi ist SAN. Es stellt ein Block-Gerät zur verfügung und ist ein Speichernetzwerk. Bei iSCSI kann auf vorhandene Technik (Ethernet) aufgebaut werden. Entsprechende Hardware vorausgesetzt kann man z.B. 4 Ethernetkanaele buendeln und so 4 GBit Datentransfer hinkriegen. Weil die SCSI-Befehle ziemlich CPU-intensiv sind gibt es auch extra iSCSI-HBAs.
gruss,
anniy
Ich habe kurz überlegt mich hier einzuhängen, aber ich lasse es.
iSCSI is ganz lustig, in Produktivbetrieb durchaus interessant, wenn man es richtig macht. Je nach Anforderung zimmert man dann auch wieder ein eigenes Netz für iSCSI hoch.
iSCSI HBAs sind nett, kostengünstiger sind aber meist Multifunctional-NICs, wie sie z.B. HP in den ProLiants verbaut. 100 € zahlen und sich über einen iSCSI HBA freuen. Wenn man es doch dediziert haben will - NIC einbauen, 100 € zahlen und fertig.
Der Begriff "eine SAN" ist total daneben. Da dreht sich mir immer der Magen um.... Du hast in deinem SAN (dem Netzwerk....) sicherlich ein oder mehrere intelligente Plattensubsysteme, gerne aus Storages genannt, vielleicht auch noch ein paar Tapes (Einzellaufwerke über SCSI-2-FC Bridges oder native FC, Autoloader, Libraries oder Silos - sucht euch was aus.) oder irgendwas anderes, was SCSI spricht und über Bridges integriert wird.
Oft kann man auch Speichersysteme in mehrere Welten integrieren, Fibre-Channel ist ja nicht das einzige Protokoll was man in einem SAN sprechen kann. Kommt ein Mainframe dazu, ist ESCON / FICON mit dabei. Einfache Systeme werden per iSCSI angebunden, der Rest per FC. Die passenden Switches oder Directoren vorausgesetzt, braucht man dafür noch nicht mal unterschiedliche aktive Netzwerkkomponenten.
NAS Systeme sind in einem SAN durchaus üblich um Speicherplatz per SMB/CIFS, NFS, FTP o.ä. zu exportieren. Gibt da ganz nette Sauereien hinsichtlich hochverfügbarer NAS Header, welche direkt an Speichersysteme geflanscht werden.
Das Thema ist sicherlich komplexer als hier im Thread dargestellt.
Was der TE will ist kein Anwendungsfall für ein Storage in einem SAN. Ich würde eher Richtung iSCSI mit Software-Target und Software-Initiator tendieren und dann per mdadm einen Mirror aufsetzen.
iscsi ist SAN. Es stellt ein Block-Gerät zur verfügung und ist ein Speichernetzwerk. Bei iSCSI kann auf vorhandene Technik (Ethernet) aufgebaut werden. Entsprechende Hardware vorausgesetzt kann man z.B. 4 Ethernetkanaele buendeln und so 4 GBit Datentransfer hinkriegen. Weil die SCSI-Befehle ziemlich CPU-intensiv sind gibt es auch extra iSCSI-HBAs.
gruss,
anniy
klassisch haste vollkommen recht, und auch die allgemeine doku dazu gibt dir recht. aber wenn ich Ethernet mit in verbindung von SAN höre.... naja nach meiner auffassung passt das nicht zusammen.
Du darfst das nicht mixen. Auch Fiberchannel ist ein Netzwerk, nur eine andere Technik.
Mit Ethernet kannst du halt im physikalischen Netz mehrere logische Netze gleichzeitig fahren, z.B. 10.10.0.1/24 und 192.168.0.1/24.
Oder aber auch noch zusätzlich iSCSI, welches ja ebenfalls ueber TCP/IP geht.
Du kannst aber natuerlich auch ein komplett getrenntes SAN mit Ethernet aufbauen, so wie Du es auch mit Fiberchannel machen wuerdest.
Streng genommen ist es nur ein Kabel und ein Protokoll ...
gruss,
anniy
Ich habe kurz überlegt mich hier einzuhängen, aber ich lasse es.
hat wohl nicht geklappt ;)
iSCSI is ganz lustig, in Produktivbetrieb durchaus interessant, wenn man es richtig macht. Je nach Anforderung zimmert man dann auch wieder ein eigenes Netz für iSCSI hoch.
Genau das meinte ich gerade
Der Begriff "eine SAN" ist total daneben. Da dreht sich mir immer der Magen
um.... Du hast in deinem SAN (dem Netzwerk....) sicherlich ein oder mehrere intelligente Plattensubsysteme, gerne aus Storages genannt, vielleicht auch noch ein paar Tapes (Einzellaufwerke über SCSI-2-FC Bridges oder native FC, Autoloader, Libraries oder Silos - sucht euch was aus.) oder irgendwas anderes, was SCSI spricht und über Bridges integriert wird.
Ich fasse den Begriff als "Wolke" auf, eben als "Black Box" sozusagen. Ich kann ja mehrere davon haben. Darum schreib ich "eine". In der Wolke ist das Netzwerk, das habe ich aber erstmal nicht betrachtet. Aber natuerlich hast Du eigentlich recht damit.
Allerdings ist fuer mich die Wolke NUR der Storage, nicht z.B. die Tapes, die ja dann AM Storage hängen.. bzw. umgekehrt.
NAS Systeme sind in einem SAN durchaus üblich um Speicherplatz per SMB/CIFS, NFS, FTP o.ä. zu exportieren. Gibt da ganz nette Sauereien hinsichtlich hochverfügbarer NAS Header, welche direkt an Speichersysteme geflanscht werden.
Ja eben, AN :) Genau das meine ich ja. Block(SAN)->NAS->Client. aber das NAS ist ja nicht IM SAN.
Was der TE will ist kein Anwendungsfall für ein Storage in einem SAN. Ich würde eher Richtung iSCSI mit Software-Target und Software-Initiator tendieren und dann per mdadm einen Mirror aufsetzen.
Nein, er wollte ein NAS, aber fuer die beschriebene Umgebung halte ich das fuer Unsinn. Deinem Vorschlag hier iSCSI einzusetzen schliesse ich mich an.
Naja, iSCSI ist ja eben auch SAN. Und der Mirror war ja genau das was ich damit vorgeschlagen habe. Ob ich jetzt Fibrechannel oder iSCSI nehme war mir da erstmal prinzipiell egal, aber ich schliesse mich diesem Vorschlag an. Ist in dem Fall wohl das sinnvollste.
gruss,anniy
Du darfst das nicht mixen. Auch Fiberchannel ist ein Netzwerk, nur eine andere Technik.
Mit Ethernet kannst du halt im physikalischen Netz mehrere logische Netze gleichzeitig fahren, z.B. 10.10.0.1/24 und 192.168.0.1/24.
Oder aber auch noch zusätzlich iSCSI, welches ja ebenfalls ueber TCP/IP geht.
Du kannst aber natuerlich auch ein komplett getrenntes SAN mit Ethernet aufbauen, so wie Du es auch mit Fiberchannel machen wuerdest.
Streng genommen ist es nur ein Kabel und ein Protokoll ...
gruss,
anniy
nett wie du das erklärst, aber als großen vorteil von iscsi wird immer wieder erwähnt, dass man ja eben kein dediziertes netz für dieses SAN benötigt und dann doch ein dediziertes nimmt??? irgendwie sonderbar oder?
wenn ich ein dedizirtes lan nehme, kann ich doch gleich ein echtes SAN nehmen.
aber gut, sind wohl verschiedene ansichten...
Nein, er wollte ein NAS, aber fuer die beschriebene Umgebung halte ich das fuer Unsinn. Deinem Vorschlag hier iSCSI einzusetzen schliesse ich mich an.
ich finde es gewagt zu behaupten, dass es nicht sinnvoll sei, wir alle kennen nur ein bruchteil der infos, die dafür sorgen, dass man diese aussage so stüzen können.
ggf ist eine FW zwischen diesen beiden systemen (server und NAS) und man will dieses NAS nicht über die FW öffnen. hier könnte durchaus ein rsync über ssh getunnelt sinnvoll sein.
aber gut, auch hier der frage der sichtweise :)
Spontan fällt mir cron + rsync ein (es werden nur Änderungen übertragen, da gehen auch große Datenbestände recht flott zum Abgleich) - allerdings nicht in Echtzeit.
Mit rsync wird die Sicherung momentan gemacht.
Allerdings werden da laut Kollege sämtliche Daten übertragen?! Jedenfalls dauert das ganze sehr sehr lange, 10 Stunden oder so.
Gibt es da einen Schalter das nur Änderungen übertragen werden?
Wenn das paarmal am Tag durchrennt dürfte das auch reichen...
Ein logisches Raid klingt auch ganz interessant, wie lässt sich sowas einrichten?
hi,
bei rsync werden immer nur differenzen übertagen.
das rsync schaut sich eine datei an, teilt diese in eine bestimmte größe auf und scheckt diese teil-dateien beim gegenüber auf gleichheit. ist dieser teil gleich, wird nciht übertragen, ansonsten wird eben diese teil-datei gesendet.
wenn also die dateien sich laufend ändern (z.b. man für eine sicherung tar-balls erstellt), dann wird auch alles komplett übertragen.
wenn dir das zu lang dauert, muss man wohl das netz aufbohren, ggf. könnte eine kompression helfen, aber das erhöht die cpu-leistung und kann damit auch mal nach hinten los gehen...
nett wie du das erklärst, aber als großen vorteil von iscsi wird immer wieder erwähnt, dass man ja eben kein dediziertes netz für dieses SAN benötigt und dann doch ein dediziertes nimmt??? irgendwie sonderbar oder?
wenn ich ein dedizirtes lan nehme, kann ich doch gleich ein echtes SAN nehmen.
aber gut, sind wohl verschiedene ansichten...
Das heisst nur das der Einstieg leichter ist. Das ist ein Vorteil.
Gruss, anniy
iSCSI ist einfach billiger. Ich brauche die Netze nicht zu trennen, ich brauche nicht mal VLANs, ich brauche nicht mal getrennte IP-Subnetze. Nur wenn ich es richtig machen will, dann lange ich ganz schnell wieder bei dedizierten NICs, eigenen IP-Subnetzen, VLANs, und schlussendlich, bei eigenen aktiven Netzwerkkomponenten.
iSCSI ist einfach billiger. Ich brauche die Netze nicht zu trennen, ich brauche nicht mal VLANs, ich brauche nicht mal getrennte IP-Subnetze. Nur wenn ich es richtig machen will, dann lange ich ganz schnell wieder bei dedizierten NICs, eigenen IP-Subnetzen, VLANs, und schlussendlich, bei eigenen aktiven Netzwerkkomponenten.
Genau das war gemeint :)
Genau das war gemeint :)
Und mit dem Erzählen von solchen Weisheiten verdiene ich meine Brötchen. :) Wären doch nur alle Kunden so empfänglich für meine Worte, dann würde ich auch mehr Fabric-Ports verkaufen.... hach ja...
Ich verdiene Sie indem ich es aufsetze *5* :D
gruss,
anniy
Ich finde das Sizen von solchen Lösung viel interessanter als das Installieren. Installieren ist ja nur doing - aber das Planen einer solchen Lösung... was ich schon für verstrahlte Anforderungen von Kunden hatte... :rolleyes:
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.