Apollon Koutlidis wrote:
Εννοείς δηλαδή ότι ένα Cyrus imapd murder με μια ντουζίνα backends,
mailbox replication σε άλλη μια ντουζίνα backends, shared folders, quota
management και διάφορα άλλα φίτσουρς μπορεί εύκολα και απλά να γίνει
migrate σε dovecot;;;
Εύκολα και απλά όχι, αλλά αφού και τα δύο υποστηρίζουν π.χ. Maildir format
τουλάχιστον *μπορεί* να γίνει - σε αντίθεση με proprietary formats που στην
καλύτερη περίπτωση θα το πληρώσεις πολύ ακριβά, στη χειρότερη θα πληκτρολογείς
τα mail των χρηστών στο νέο σύστημα. Από εκτυπώσεις. :-)
Τα μεγέθη τόσο του δημοσίου όσο και οποιουδήποτε αρκούντως μεγάλου
οργανισμού αλλάζουν άρδην τις παραμέτρους μιας εγκατάστασης. Όσο
μεγαλώνει ο οργανισμός, τόσο μικρότερες είναι οι ανοχές σε διακοπές
παροχής των υπηρεσιών, και τόσο πιο δύσκολο γίνεται να αποφύγεις αυτές
τις διακοπές. Όταν έρθει η ώρα του kernel patch, πως θα κάνεις
επανεκκίνηση τον backend Cyrus χωρίς να διακόψεις την πρόσβαση των
χρηστών στα αντίστοιχα mailboxes; Αν κάνεις rolling restarts θα έχεις
downtime window πολλαπλάσιο του πλήθους των backends, αν δεν κάνεις
rolling restarts θα αποκλείσεις όλους τους χρήστες για το διάστημα της
επανεκκίνησης. Πόσες τέτοιες επανεκκινήσεις μπορείς να κάνεις το μήνα;
Και πόσα patches μηνιαίως απαιτούν επανεκκινήσεις; Πόσα επιπλέον outages
μπορείς να περιμένεις διότι απαιτεί firmware upgrade το SAN fabric, το
Storage platform, ο router, το Ethernet switch; Αντίο SLA...
Μπαίνουμε σε πολύ τεχνικά θέματα, αλλά θεωρώ ότι με τις σύγχρονες τεχνολογίες
τόσο σε επίπεδο λογισμικού όσο και σε επίπεδο υλικού γίνεται όλο και πιο εύκολο
(τηρουμένων των αναλογιών) να αποφύγεις το downtime. Κι αφού έφερες το
παράδειγμα του Cyrus, η λύση είναι το redundancy, που στον Cyrus εκφράζεται με
το CyrusMurder - φυσικά έχεις στήσει πάνω από έναν frontend και πάνω από έναν
backend server και ρέπλικες, έτσι δεν είναι;
Αλλά έτσι κι αλλιώς, τα θέματα που θέτεις δεν αφορούν ειδικά το ανοιχτό
λογισμικό, αφορούν το λογισμικό κάθε τύπου καθώς και το hardware. Άρα η απάντηση
είναι ο σωστός εξαρχής σχεδιασμός που να προβλέπει redundancy και scalability.
Στόχος του παραπάνω είναι μόνον να επισημάνει ότι οι εγκαταστάσεις
μεγάλης κλίμακας προβάλλουν δυσκολίες και πολυπλοκότητες που δεν
απαντώνται συχνά, και ως εκ τούτου οι λύσεις που θα εφαρμοστούν
Φαντάσου οποιοδήποτε σύστημα (δικτυο, mail κλπ) σαν fractal. Εφάρμοσε το KISS
principle. Δώσε έμφαση στο modularity και φρόντισε να ελαχιστοποιήσεις (να
μηδενίσεις καλύτερα) τον αριθμό των αναντικατάστατων στοιχείων (modules), είτε
αυτά είναι software, είτε hardware, είτε sysadmins. Πιστεύω ότι υπό αυτήν την
οπτική η κλίμακα χάνει τη σημασία της όσο αφορά τη δυσκολία και την
πολυπλοκότητα και το δυσκολότερο σημείο είναι η διαθεσιμότητα των απαραίτητων
πόρων και κυρίως των ανθρώπων.
αναπόφευκτα θα είναι σε μεγάλο βαθμό "ιδιόμορφες" (για να πετάξουμε αυτό
το ad hoc από τη συζήτηση). Όπως πολύ σωστά το έθεσες, το κλειδί είναι
επαρκής τεκμηρίωση και εκπαίδευση - αλλά δεν αλλάζει το γεγονός ότι το
Να προσθέσω και τον σχεδιασμό.
λογισμικό που θα κληθεί να εξυπηρετήσει το πλήθος των προκυπτουσών
αναγκών στην πλειοψηφία των περιπτώσεων δεν θα έχει ποτέ χρησιμοποιηθεί
για να εξυπηρετήσει τέτοια μεγέθη client base | datasets | rule sets |
cluster nodes | all of the above - και νομίζω ότι δε χρειάζεται καν να
συζητήσουμε τις συνέπειες αυτού του γεγονότος. Το καλό είναι ότι με
Υπάρχει λογισμικό σε "πακέτο" (ανοιχτό ή κλειστό) που να έχει δοκιμαστεί
αυτούσιο σε πολύ μεγάλες κλίμακες; Δε νομίζω - οι πολύ μεγάλες εγκαταστάσεις
ανεξαρτήτως ανοιχτού ή κλειστού λογισμικού χρειάζονται έτσι κι αλλιώς επιπλέον
δουλειά.
λύσεις ΕΛ/ΛΑΚ τα προκύπτοντα προβλήματα μπορούν να αντιμετωπιστούν με
αλλαγές ή προσθήκες στον κώδικα. Το πρόβλημα είναι ότι αν οι ανάγκες
τροποποίησης εμφανιστούν στη μέση μιας εγκατάστασης που έχει εκτιμηθεί
ότι θα τελειώσει σε δύο μήνες... :-)
Αυτό μπορεί να συμβεί σε οποιαδήποτε περίπτωση δεν έχει σχεδιαστεί η εγκατάσταση
σωστά από την αρχή - ξανά, ανεξαρτήτως του τύπου του λογισμικού.
Σαν παλιός δίσκος, επαναλαμβάνω ξανά και ξανά την ίδια φράση: Το κλειδί
είναι στον έγκαιρο καθορισμό των αναγκών και στον εντοπισμό των
κατάλληλων, δοκιμασμένων σε αντίστοιχη κλίμακα λύσεων. Χωρίς αυτά, οι
πιθανότητες επιτυχίας ελαττώνονται δραματικά.
Ας μην ξεχνάμε και την απαιτούμενη ευελιξία της λύσης: υπάρχει η λογική "το
στήσαμε, παίζει, τελειώσαμε". Θεωρώ πως με την ολοκλήρωση μιας εγκατάστασης,
ξεκινάει ο σχεδιασμός της επέκτασης και της μετάβασης στην επόμενη αναβαθμισμένη
εγκατάσταση. Αυτό θα πρέπει να λαμβάνεται εξαρχής υπόψιν - ένα δίκτυο ή ένα
σύστημα mail είναι "ζωντανό" και οι ανάγκες (όπως και οι τεχνολογίες) αλλάζουν
συνεχώς. Θα πρέπει στον σχεδιασμό να έχει προβλεφθεί π.χ. η περίπτωση να
διπλασιαστούν οι ανάγκες πριν καν ολοκληρωθεί η εγκατάσταση. Ένα σύστημα που θα
απαιτήσει migration για να καλύψει τις νέες ανάγκες είναι αποτυχημένο, σε
αντίθεση με κάποιο που θα απαιτήσει απλώς δύο modules ακόμα.
Ποια είναι τα πεδία πιθανής εισαγωγής ΕΛ/ΛΑΚ; Πως θα συλλεχθούν οι
ανάγκες για το κάθε πεδίο; Σε ποια πεδία υπάρχουν περισσότερες
προηγούμενες ιστορίες επιτυχίας που ταιριάζουν με τα εδώ ζητούμενα;
Ποιοι είναι οι ρισκογόνοι παράγοντες και πως μπορούν να ελεγχθούν; Αυτού
του τύπου οι ερωτήσεις πιστεύω ότι πρέπει να απασχολήσουν κατ' αρχήν την
κοινότητα - οι τεχνικές λεπτομέρειες θα ακολουθήσουν. Στην αντίθετη
περίπτωση IMO είμαστε σαν τους τυφλούς που ψηλαφούν τον ελέφαντα...
Φιλικά,
Απόλλων
Συμφωνώ. Προσεκτικός σχεδιασμός σε κάθε στάδιο και σε κάθε κλίμακα, αυτό είναι
το ζητούμενο.
Το θέμα είναι ότι το μέγεθος και η πολυπλοκότητα δεν είναι λογικό να αποτελούν
αποτρεπτικό παράγοντα για τη χρήση ανοιχτού λογισμικού - ίσα ίσα που τα μέχρι
τώρα δεδομένα δείχνουν το αντίθετο.
Θ.
--
Theodore=J.=Soldatos=_\_======================================================
= theodore [ at ] eexi [ dot ] gr =_/_====== "Greed is never good" - Linus Torvalds ========