[GastForen

  • Suche
  • Hilfe
  • Lesezeichen
  • Benutzerliste
Forenindex -- Lesezeichen

1 Lesezeichen für delayed_ack

Helios Server mit anderen AFP Server synchronsieren
Servus Pronto,

Antwort auf [ pronto ] Macht demnach zu den ca. 1.500.- Eur Lizenzkosten für den ExtremeZ-IP Server maximal noch mal 400.- Eur Windows Server CALs. Dem gegenüber stünden 4 - 5.000 Eur Helios Udate-Kosten und quasi ein Zwangsdowngrade unserer 250er User Lizenz, weil dafür wollten die 10.000.- Eur oder mehr haben, wenn ich mich recht erinnere.


Hmm... komisch, ich dachte ein Upgrade inkl. Downsizing-Option von 250 auf 20 würde 1.700,- kosten. Kann mich aber täuschen, bin in der Thematik als reiner Integrator und Software-Produzent nicht so drin.

Antwort auf: Fazit: Helios kam damit genau zum falschen Zeitpunkt mit dieser Daumenschraube bei uns an.


Ja, das hörte man öfter...


Antwort auf: Nun gut, im Prinzip läufts aber wieder darauf hinaus, alles über eine Workstation laufen zu lassen. Das Hauptproblem bei diesem Setup wird vermutlich die Zeit sein aber zur Not muss ich mir halt eine Workstation in den Serverraum stellen und diese dann an ein GBit Interface am Coreswitch anschließen. Das ist zwar besser als das direkt über mein Büro laufen zu lassen aber wirklich prickelnd schätze ich das auch nicht ein.


Ein MacPro mit 2 GBit-Interfaces, passendes Routing und Du solltest in dem Setup keinen Unterschied zu einer direkten Verbindung beider Server per GBit-Ethernet spüren. Wichtig ist, daß man "-z" bei rsync ausläßt in so einer Situation (die Komprimiererei bremst mehr als daß sie nützt -- zumindest meine Erfahrung in Gbit-LAN-Situationen). Oder anders ausgedrückt: Vorher bisserl testen. Und bei richtig grottiger Performance sofort

Code
sudo echo "net.inet.tcp.delayed_ack=2" >> /etc/sysctl.conf 


auf dem Mac ausführen, Reboot machen und nochmal probieren.

Antwort auf: Okay, ich muss das nicht alles auf einen Rutsch machen, ich kann auch beide Server eine Zeitlang parallel betreiben und Volume für Volume umziehen. Da es sich dabei um eine einmalige Sache handelt zur Not noch vertretbar.


Mir scheint, Du hast den inkrementellen Sync-Ansatz noch nicht ganz verinnerlicht. Du stellst beide Server parallel auf, läßt dann stur initial den Sync laufen -- evtl. sogar mit gesetzter Option "--bwlimit=KBPS" (limit I/O bandwidth; KBytes per second) damit die in der Produktion auch noch arbeiten können.

Dann kommt der Tag X und Du läßt noch einmal rsync mit identischen Parametern laufen. Dieses Nachsyncen wird deutlich schneller laufen als der initiale Sync, weil nun nur noch die Änderungen gesynct werden.

Da ich grad erlebt habe, wie ein sehr großes Systemhaus mit schwachsinnigen rsync-Parametern eine Server-Migration beinahe erfolgreich sabotiert hätte, noch schnell sinnige rsync-Parameter anbei (immer identische Parameter für initialen und Folge-Syncs nehmen):

Code
rsync -v -rltpogu --delete --force 


(Unter MacOS X natürlich "-E" nicht vergessen)

Migration vierer Suns auf eine neue dicke. Initialer Sync mehrere Tage, danach nächtlich inkrementeller Sync. Letzter inkrementeller Sync am Tag X im Bereich von ein paar Stunden. Und da geht's um TBytes im zweistelligen Bereich und AFAIR mehr als 300 User, die da jeden Tag auf den Server-Volumes herumwurschteln.

Gruss,

Thomas
...
Thomas Kaiser
26. Sep 2010, 12:04