Καλό Σαββατοκύριακο από Ηράκλειο,
Στο Λύκειο Χάρακα έχουμε εργαστήριο με περίπου 10 Η/Υ Celeron 1.8 GHz 512MB RAM. Μέχρι τώρα λειτουργούν standalone Ubuntu 8.04 Οι εποχές είναι δύσκολες και το σχολείο δεν έχει να διαθέσει για την αγορά "σύγχρονου" server. Περιμένω την άποψη σας στο επόμενο σενάριο:
Ένας σταθμός εργασίας να "παίξει" το ρόλο του LTSP server. Ο σκληρός δίσκος αρκεί, μπορούμε στην εγκατάσταση να προβλέψουμε και ένα επαρκές swap. Οι υπόλοιποι σταθμοί εργασίας όπως ήδη είναι στημένοι, μπορούν να λειτουργήσουν standalone εκκινώντας από το δίσκο τους με Ubuntu 8.04 είτε σαν FAT clients εκκινώντας από το δίκτυο, έχουν και swap που από όσο γνωρίζω το FAT image είναι κατάλληλο και το αξιοποιεί. Περιμένω λοιπόν θεωρητικά, χωρίς καμιά hardware αναβάθμιση στον LTSP "server" ολόκληρο το εργαστήριο να "στέκεται" με αξιοπρέπεια, με την προϋπόθεση πως δεν θα "εμφανιστεί" thin client και ο LTSP "server" δε θα χρησιμοποιείται και σα σταθμός εργασίας από τους μαθητές, παρά μόνο για εργασίες διαχείρισης, ώστε να μπορεί να παίξει αποτελεσματικά την αποστολή του: να δώσει το λειτουργικό στους υπόλοιπους (ουσιαστικά file server) και να έχουμε κεντρική διαχείριση χρηστών, τάξης, περιοχών, αναβαθμίσεων κλπ.
Υπάρχουν κάποια σημεία που πρέπει να προσέξουμε για να έχουμε περισσότερο βελτιστοποιημένο σενάριο; Καταγράφω κάποιες σκέψεις:
1. RAM threshold πολύ χαμηλό, ώστε και τυχαίος πολύ ασθενικός σταθμός εργασίας να συνδεθεί, να μην κάνει προσπάθεια να ξεκινήσει thin. Ή θα ξεκινήσει FAT ή δεν θα ξεκινήσει καθόλου.
2. Προετοιμασία του εικονικού δίσκου κάπου αλλού αν υπάρχει η δυνατότητα (πχ ακόμα και ο προ 5ετίας φορητός του καθηγητή είναι περισσότερο γρήγορος από τον LTSP "server") και αντιγραφή του εικονικόύ δίσκου στον LTSP "server" για να τον "μοιράζει" στην κανονική λειτουργία.
3. Συμπιεσμένος αν υπάρχει η δυνατότητα ή ασυμπίεστος εικονικός δίσκος;
4. Μπορεί ο εικονικός δίσκος να αντιγραφεί σε έναν πραγματικό δίσκο σταθμού εργασίας; Πλεονέκτημα: αυτός ο σταθμός εργασίας να είναι ο πρότυπος client και εκεί να παραμετροποιούμε εύκολα το client περιβάλλον, να κάνουμε αναβαθμίσεις και εγκαταστάσεις εφαρμογών χωρίς να χρειάζεται chroot. Όποτε θέλουμε δεν έχουμε παρά να εφαρμόζουμε την αντίστροφη διαδικασία, δηλαδή αντιγραφή του πραγματικού πρότυπου δίσκου στον εικονικό δίσκο του LTSP "server" ο οποίος και θα διανέμεται στη συνέχεια.
5. Τι από τα επόμενα περιμένουμε να βελτιστοποιήσει περισσότερο;
Gigabit network card στον LTSP server
Αναβάθμιση RAM στον LTSP server. 1 ή 2 GB θα δώσει διαφορά;
Proxy στον LTSP server θα βοηθήσει ή θα τον κάνει ποιό αργό στη βασική του υπηρεσία (ουσιαστικά file service)
Ευχαριστώ,
Βερβελάκης Γιώργος
Τ.Υ. ΚεΠληΝεΤ Ηρακλείου
Γεια σου Γιώργο,
Λίγη ανάλυση πριν πάμε στις απαντήσεις:
Ας υποθέσουμε ότι οι παλιοί σκληροί δίσκοι των σταθμών εργασίας που αναφέρεις έχουν μέση ταχύτητα 100 Mbps (όχι σε MByte που μετράμε συνήθως τους δίσκους αλλά σε Mbit για να συγκρίνουμε με το τοπικό δίκτυο).
Και ας υποθέσουμε επίσης ότι κάθε client συνδέεται με 100 Mbps ταχύτητα με το server.
- Η συμπίεση του εικονικού δίσκου επιτρέπει στο server να στείλει περίπου τριπλάσια δεδομένα, δηλαδή περίπου 300 Mbps ανά client, χωρίς να επιβαρύνει καθόλου τη CPU του server, αφού η συμπίεση δεν γίνεται real time.
- Το σύστημα αρχείων 'squashfs' λόγω διαφορετικών αναγκών/σχεδιασμού είναι πιο ελαφρύ από τα συνηθισμένα ext2/3/4 συστήματα αρχείων (π.χ. δεν χρειάζεται να κρατάει πληροφορία για disc blocks), κι έτσι δίνει έναν ακόμα λόγο για μεγαλύτερη ταχύτητα μέσω δικτύου.
- Αν ο server έχει αρκετή RAM, τότε μπορεί να κρατήσει στη μνήμη είτε ολόκληρο τον εικονικό δίσκο των clients, είτε ένα μεγάλο μέρος του. Εδώ βοηθάει για δεύτερη φορά η συμπίεση, αφού έτσι χρειαζόμαστε 3 φορές λιγότερη RAM. Έτσι μπορεί να απαντάει πολύ γρήγορα στα disk reads των clients, σαν να ήταν SSD δίσκος, αφού έχει πολύ μικρό latency σε σχέση με τα disk reads από κανονικό δίσκο. Για παράδειγμα, σε κάποιο υπερσύγχρονο εργαστήριο που δοκίμασα, οι clients ξεκινούσαν σε 50 δευτερόλεπτα τοπικά, ενώ μέσω δικτύου σε 12.
- Αν προσπαθούσαμε για οικονομία να κόψουμε RAM από τον server και του αφήναμε π.χ. μόνο 512 MB, τότε δεν θα μπορούσε να κάνει cache αρκετό κομμάτι από τον εικονικό δίσκο, και για κάθε client θα έπρεπε να το ξαναδιαβάζει εξ' αρχής, ακυρώνοντας εντελώς το πλεονέκτημα του μικρού latency που λέγαμε παραπάνω.
- Αν προσπαθούσαμε να κόψουμε ταχύτητα δικτύου και αντί για gigabit ταχύτητα server <=> switch να είχαμε 100mbps, τότε αν π.χ. 5 clients ζητούσαν μαζί δεδομένα δίσκου, η ταχύτητα θα έπεφτε στα 20 Mbps για τον καθένα.
Άρα, και η RAM και η gigabit σύνδεση τουλάχιστον από τον server ως το switch είναι πολύ σημαντικές για fat clients.
Αντίθετα, η CPU του server δεν είναι καθόλου σημαντική, θέλουμε ίσα-ίσα να μπορεί να διαβάζει 1 Gbps από τη RAM και να το στείλει στην κάρτα δικτύου, δηλαδή μπορεί να είναι και π.χ. Celeron @1GHz.Επομένως:
1) Αρκεί να θέσεις LTSP_FATCLIENT=True κεντρικά στο lts.conf. Αυτό απενεργοποιεί το autodetection μέσω RAM threshold.
2) Είτε έτσι, είτε πατάς "συμπίεση εικονικού δίσκου" το βράδυ και το βρίσκεις έτοιμο το πρωί. :)
Είτε χρησιμοποιείς κάποιον από τους fat clients σαν server.
3) Συμπιεσμένος.
4) Όχι. Θα χρειαστούν πολλές αλλαγές upstream στο LTSP μέχρι να υποστηριχθεί κάτι τέτοιο.
5) Χρειάζεται οπωσδήποτε η RAM, αλλά και η gigabit σύνδεση του server είναι κι αυτή πολύ ωφέλιμη. Το ακριβές νούμερο για τη RAM εξαρτάται κι από το μέγεθος του εικονικού δίσκου και από τη γενικότερη χρήση του εργαστηρίου.
Για τον proxy, λογικά η ταχύτητα που θα προσφέρει στο browsing θα είναι πιο σημαντική από όποια καθυστέρηση επιφέρει.