Εφαρμογή SDN για δυναμική δρομολόγηση σε Software Defined Networks ΔΙΠΛΩΜΑΤΙΚΗ ΕΡΓΑΣΙΑ. Παληού Ε. Δέσποινα

ΕΘΝΙΚΟ ΜΕΤΣΟΒΙΟ ΠΟΛΥΤΕΧΝΕΙΟ ΣΧΟΛΗ ΗΛΕΚΤΡΟΛΟΓΩΝ ΜΗΧΑΝΙΚΩΝ ΚΑΙ ΜΗΧΑΝΙΚΩΝ ΥΠΟΛΟΓΙΣΤΩΝ ΤΟΜΕΑΣ ΕΠΙΚΟΙΝΩΝΙΩΝ ΗΛΕΚΤΡΟΝΙΚΗΣ ΚΑΙ ΣΥΣΤΗΜΑΤΩΝ ΠΛΗΡΟΦΟΡΙΚΗΣ Εφαρμογή SDN για δυναμική δρομολόγηση σε Software Defined Networks ΔΙΠΛΩΜΑΤΙΚΗ ΕΡΓΑΣΙΑ Παληού Ε. Δέσποινα Επιβλέπων: Ευστάθιος Συκάς Καθηγητής Ε.Μ.Π. Αθήνα, Οκτώβριος 2016 1

2

ΕΘΝΙΚΟ ΜΕΤΣΟΒΙΟ ΠΟΛΥΤΕΧΝΕΙΟ ΣΧΟΛΗ ΗΛΕΚΤΡΟΛΟΓΩΝ ΜΗΧΑΝΙΚΩΝ ΚΑΙ ΜΗΧΑΝΙΚΩΝ ΥΠΟΛΟΓΙΣΤΩΝ ΤΟΜΕΑΣ ΕΠΙΚΟΙΝΩΝΙΩΝ ΗΛΕΚΤΡΟΝΙΚΗΣ ΚΑΙ ΣΥΣΤΗΜΑΤΩΝ ΠΛΗΡΟΦΟΡΙΚΗΣ Εφαρμογή SDN για δυναμική δρομολόγηση σε Software Defined Networks ΔΙΠΛΩΜΑΤΙΚΗ ΕΡΓΑΣΙΑ Παληού Ε. Δέσποινα Επιβλέπων: Ευστάθιος Συκάς Καθηγητής Ε.Μ.Π. Εγκρίθηκε από την τριμελή εξεταστική επιτροπή την 25η Οκτωβρίου 2016... Ευστάθιος Συκάς Καθηγητής Ε.Μ.Π.... Μιχαήλ Θεολόγου Καθηγητής Ε.Μ.Π.... Γεώργιος Στασινόπουλος Καθηγητής Ε.Μ.Π. Αθήνα, Οκτώβριος 2016 3

... Παληού Ε. Δέσποινα Διπλωματούχος Ηλεκτρολόγος Μηχανικός και Μηχανικός Υπολογιστών Ε.Μ.Π. Copyright Παληού Ε. Δέσποινα, 2016 Με επιφύλαξη παντός δικαιώματος. All rights reserved. Απαγορεύεται η αντιγραφή, αποθήκευση και διανομή της παρούσας εργασίας, εξ ολοκλήρου ή τμήματος αυτής, για εμπορικό σκοπό. Επιτρέπεται η ανατύπωση, αποθήκευση και διανομή για σκοπό μη κερδοσκοπικό, εκπαιδευτικής ή ερευνητικής φύσης, υπό την προϋπόθεση να αναφέρεται η πηγή προέλευσης και να διατηρείται το παρόν μήνυμα. Ερωτήματα που αφορούν τη χρήση της εργασίας για κερδοσκοπικό σκοπό πρέπει να απευθύνονται προς τον συγγραφέα. Οι απόψεις και τα συμπεράσματα που περιέχονται σε αυτό το έγγραφο εκφράζουν τον συγγραφέα και δεν πρέπει να ερμηνευθεί ότι αντιπροσωπεύουν τις επίσημες θέσεις του Εθνικού Μετσόβιου Πολυτεχνείου. 4

Περίληψη Σκοπός της παρούσας διπλωματικής εργασίας είναι η ανάπτυξη μιας εφαρμογής SDN που ελέγχει εξωτερικά τον ελεγκτή ενός SDN δικτύου και αποσκοπεί στον επαναπροσδιορισμό της δρομολόγησης στο δίκτυο προκειμένου να επιτευχθεί δρομολόγηση με ενεργειακά βέλτιστο τρόπο. Για την επιλογή της δρομολόγησης λαμβάνονται υπόψιν ενεργειακά μοντέλα των συσκευών καθώς και στατιστικά της κίνησης στις ροές του δικτύου, που προέκυψαν μετά από κατάλληλη παραμετροποίησή του μέσω του ελεγκτή. Τα Ευφυή Προγραμματιζόμενα Δίκτυα μέσω του βασικού πρωτοκόλλου OpenFlow, διαχωρίζουν το επίπεδο ελέγχου από το επίπεδο προώθησης δεδομένων παρέχοντας έναν κεντρικοποιημένο έλεγχο του δικτύου μέσω του ελεγκτή. Ο ελεγκτής που επιλέχθηκε για τη διπλωματική είναι ο OpenDaylight controller ενώ για την τοπολογία του δικτύου χρησιμοποιήθηκε το Mininet που είναι εξομοιωτής δικτύων. Η τοπολογία που επιλέχθηκε προσομοιάζει τις τοπολογίες που επιλέγονται για τα Data Centers λόγω του μεγάλου ποσοστού ενέργειας που καταναλώνεται σ αυτά. Για την εκμάθηση της τοπολογίας του δικτύου καθώς και για την παραμετροποίησή του χρησιμοποιήθηκε το REST api του OpenDaylight, ενώ για την εύρεση της βέλτιστης δρομολόγησης χρησιμοποιήθηκε το λογισμικό CPLEX. Λέξεις Κλειδιά : OpenFlow, OpenDaylight Controller, REST api, ροή, στατιστικά ροής, Mininet, ενεργειακή δρομολόγηση 5

6

Abstract The purpose of this diploma thesis is to develop an SDN app that externally manages the Controller of an SDN network and which aims to reformulate the network routing, with a view to achieve routing at an optimal consumption of energy. For the process of selection of routing we consider the energy models of the devices as well as network traffic flow statistics that have been derived through the proper configuration achieved via the Controller. The Software Defined Networks, through the essential protocol OpenFlow, decouple the control plane from the data plane, providing centralized control of the network via the Controller. The Controller chosen for this thesis is the OpenDaylight Controller, while for the network's topology the network emulator Mininet was used. The topology chosen emulates Data Centers topologies owing to their vast consumption of energy. For the network topology learning and configuration we used Rest api, while for finding optimal routes we used CPLEX. Key Words: OpenFlow, OpenDaylight Controller, REST api, flow, flow statistics, Mininet, Energy Aware Routing 7

8

Ευχαριστίες Η διπλωματική αυτή εργασία αποτελεί το επιστέγασμα της φοιτητικής μου πορείας στο Εθνικό Μετσόβιο Πολυτεχνείο και θα ήθελα να εκφράσω τις ευχαριστίες μου στους ανθρώπους που στάθηκαν δίπλα μου και συνετέλεσαν σε αυτήν. Αρχικά, ιδιαίτερες ευχαριστίες οφείλω στον επιβλέποντα καθηγητή μου, κ. Ευστάθιο Συκά για την καθοδήγηση που μου παρείχε στην επιλογή αυτού του ενδιαφέροντος θέματος καθώς και για την εμπιστοσύνη που μου έδειξε για την ανάθεση του. Επίσης θα ήθελα να ευχαριστήσω θερμά τον υποψήφιο διδάκτορα, κ. Πάρη Χαραλάμπου για την υποστήριξη και την πολύτιμη βοήθεια που μου παρείχε καθώς και για την άριστη επικοινωνία μας. Είναι ευκαιρία να ευχαριστήσω εδώ και τους φίλους μου που στάθηκαν δίπλα μου αυτά τα χρόνια, πολλοί εκ των οποίων υπήρξαν και συνεργάτες μου στη σχολή. Τους ευχαριστώ πολύ για τις δημιουργικές συνεργασίες που είχαμε, τις όμορφες αλλά και δύσκολες στιγμές που περάσαμε παρέα προκειμένου να ανταπεξέλθουμε στις απαιτήσεις της σχολής. Τέλος, θα ήθελα να εκφράσω την ευγνωμοσύνη μου στην οικογένεια μου, στα δύο μου αδέλφια και ιδιαίτερα στους γονείς μου. Με την διακριτική παρουσία τους πάντα στη ζωή μου, την εμπιστοσύνη και υποστήριξη που έδειχναν πάντα στις επιλογές μου, με βοηθήσαν να βρίσκομαι εδώ σήμερα, ως φοιτήτρια και ως άνθρωπος. Δέσποινα Ε. Παληού, Αθήνα, Οκτώβριος 2016 9

10

Πίνακας περιεχομένων Περίληψη...5 Abstract...7 Ευχαριστίες...9 1 Εισαγωγή...15 1.1 Σκοπός...15 2 Ευφυή Προγραμματιζόμενα Δίκτυα...17 2.1 Αρχιτεκτονική SDN...18 2.1.1 Επίπεδο Εφαρμογών (SDN Application)...19 2.1.2 Επίπεδο Ελέγχου (SDN Controller)...19 2.1.3 Επίπεδο Δεδομένων (SDN Datapath)...19 2.1.4 NorthBound SDN Διεπαφή (SDN NorthBound Interfaces NBI)...20 2.1.5 Διεπαφή διασύνδεσης επιπέδου ελέγχου-δεδομένων (SDN Control to DataPlane Interface CDPI)...20 2.1.6 Διαχείριση (Management & Admin)...20 2.2 Το πρωτόκολλο OpenFlow...21 2.3 OpenFlow Μεταγωγέας (OpenFlow Switch)...22 3 OpenDaylight Controller...23 3.1 Αρχιτεκτονική OpenDaylight...24 3.2 Πλατφόρμα Ελεγκτή...25 3.2.1 Βασικές Λειτουργίες Υπηρεσιών Δικτύωσης (Base Network Service Functions)...25 3.3 MD-SAL (Model Driven-Service Abstraction Layer)...27 3.4 REST API...29 3.5 Εκκίνηση OpenDaylight...30 3.6 DLUX...31 4 Mininet...33 4.1 Έναρξη Τοπολογίας στο Mininet...34 5 Data Centers...37 5.1 Άλλοι μέθοδοι εξοικονόμησης ενέργειας...38 5.2 Εξοικονόμηση ενέργειας μέσω των δικτυακών συσκευών...40 6 Ανάπτυξη εφαρμογής ελέγχου του δικτύου...43 6.1 Απαιτούμενα εργαλεία...44 6.1.1 Λογισμικό CPLEX...44 6.1.2 Η βιβλιοθήκη jq...44 6.1.3 Απαιτήσεις OpenDaylight...45 6.2 Τοπολογία...46 6.2.1 Τοπολογία των Data Centers...46 6.2.2 Τοπολογία Εφαρμογής...47 6.3 Αρχιτεκτονική Εφαρμογής...49 6.3.1 Διάγραμμα Ροής Σύνοψη εφαρμογής...52 6.4 Εκμάθηση Τοπολογίας Συστήματος...53 6.5 Μηχανισμός Συλλογής Στατιστικών...55 6.6 Υπολογισμός Βέλτιστης Ενεργειακά Δρομολόγησης...62 6.7 Εξαγωγή Αποτελεσμάτων...63 Βιβλιογραφία...67 Παράρτημα...69 11

12

Ευρετήριο εικόνων Εικόνα 1: Επισκόπηση Αρχιτεκτονικής των Software Defined Networks...18 Εικόνα 2: Δομή OpenFlow Μεταγωγέα...22 Εικόνα 3: Επισκόπηση Αρχιτεκτονικής OpenDaylight Controller (Έκδοση Beryllium) [8]...24 Εικόνα 4: Αλληλεπίδραση μεταξύ του ελεγκτή και της Southbound επέκτασης...28 Εικόνα 5: Εκκίνηση του OpenDaylight...30 Εικόνα 6: Γραφική απεικόνιση τοπολογίας του OpenDaylight μέσω του DLUX...31 Εικόνα 7: Παράδειγμα τοπολογίας στο Mininet...35 Εικόνα 8: Επισκόπηση Αρχιτεκτονικής Fattree σε Data Center...46 Εικόνα 9: Τοπολογία δικτύου εφαρμογής (OpenDaylight DLUX)...47 Εικόνα 10: Αρχιτεκτονική Συστήματος...51 Εικόνα 11: Διάγραμμα ροής της εφαρμογής...52 Εικόνα 12: Μικρή τοπολογία Παράδειγμα...59 Εικόνα 13: Τοπολογία δικτύου εφαρμογής μετά την βελτιστοποίηση (OpenDaylight DLUX)...63 Εικόνα 14: Τοπολογία δικτύου εφαρμογής μετά την βελτιστοποίηση (OpenDaylight DLUX) για ίδια ενεργειακά μοντέλα σε όλους τους μεταγωγείς...64 13

14

1 Εισαγωγή 1.1 Σκοπός Σε αυτήν τη διπλωματική εργασία αυτοματοποιείται η διαδικασία συλλογής στατιστικών στοιχείων σε Ευφυή Προγραμματιζόμενα Δίκτυα (Software Defined Networks) μικρής ή και μεγάλης κλίμακας προκειμένου να χρησιμοποιηθούν για την εύρεση αποδοτικότερης δρομολόγησης εντός του δικτύου σε πραγματικό χρόνο, με σκοπό να εξοικονομηθεί ενέργεια από τη βέλτιστη χρησιμοποίηση των πόρων του. Η ιδέα της διερεύνησης αυτής προέκυψε από την παρατήρηση πως η ολοένα κι αυξανόμενη χρησιμοποίηση του διαδικτύου και η ανάγκη ύπαρξης μεγάλων υποδομών σε κέντρα δεδομένων (data centers) επιβαρύνει το περιβάλλον λόγω της απαίτησης για κατανάλωση ενέργειας. Στα πλαίσια της εργασίας χρησιμοποιήθηκε ο OpenDaylight Controller (ODL). Μέσω του ODL, ο διαχειριστής δύναται απομακρυσμένα και από οποιοδήποτε μηχάνημα εκτός του δικτύου να συλλέξει πληροφορίες για το δίκτυο, αλλά και να του στείλει επίσης πίσω κατάλληλες παραμετροποιήσεις για τη συνέχιση και διαφοροποίηση της λειτουργίας του. Δημιουργήθηκε εφαρμογή που εξωτερικά ελέγχει τον ODL, ο οποίος με τη σειρά του εποπτεύει το δίκτυο. Η τοπολογία που επιλέχθηκε τρέχει στο εργαλείο εξομοίωσης δικτύων Mininet, με την εφαρμογή να μπορεί να χρησιμοποιηθεί χωρίς αλλαγή σε οποιαδήποτε τοπολογία και να κληθεί από οποιοδήποτε μηχάνημα. Σε πρώτη φάση συλλέγονται πληροφορίες για την τοπολογία του εκάστοτε δικτύου μέσω του ODL. Ανάλογα τις πληροφορίες αυτές στέλνονται κατάλληλες παραμετροποιήσεις για την τροποποίηση στοιχείων και στη συνέχεια γίνεται συλλογή, επεξεργασία και εξαγωγή των στατιστικών. Στη συνέχεια με τη χρήση αυτών, γίνεται επιλογή για το ποιες διεπαφές θα παραμείνουν ανοιχτές και ποιες θα κλείσουν. Η εφαρμογή τρέχει διαρκώς και σε πραγματικό χρόνο, προκειμένου να εποπτεύει την ενεργειακά αποδοτική χρησιμοποίηση του εκάστοτε δικτύου. 15

16

2 Ευφυή Προγραμματιζόμενα Δίκτυα Η εξάπλωση των κινητών ευφυών συσκευών, η ανάγκη εικονικοποίησης των μηχανημάτων καθώς και οι νέες υπηρεσίες Cloud επιτάσσουν τη δημιουργία μιας νέας αρχιτεκτονικής στα δίκτυα προκειμένου να ικανοποιηθούν οι νέες ανάγκες στις οποίες δεν μπορούν να ανταπεξέλθουν τα παραδοσιακά δίκτυα. Έτσι με τη βοήθεια του Ανοικτού Λογισμικού, η κοινότητα Open Networking Foundation (ONF) εισήγαγε τη νέα γενιά αρχιτεκτονικής δικτύων, τα Λογισμικώς Καθοριζόμενα Δίκτυα (Software Defined Networks). Το Software Defined Networking (SDN) στοχεύει στο να δοθεί η δυνατότητα στους διαχειριστές δικτύων να μπορούν άμεσα και απομακρυσμένα να ελέγξουν το δίκτυο μέσω ενός κεντρικοποιημένου ελέγχου που προσφέρουν. Το SDN μπορεί να χρησιμοποιήσει υποδομή διαφορετικών κατασκευαστών προκειμένου να σχεδιάσει, ελέγξει και διαχειριστεί τα δίκτυα που γίνονται πιο ευέλικτα μέσω της κεντρικής ιδέας του SDN, τον διαχωρισμό του επιπέδου ελέγχου από το επίπεδο δεδομένων. Το επίπεδο ελέγχου είναι υπεύθυνο για τη δρομολόγηση των πακέτων ενώ το επίπεδο δεδομένων για τη μεταφορά τους. Σε αντίθεση με την παραδοσιακή TCP/IP αρχιτεκτονική που η δρομολόγηση γίνεται βάσει στατικών κανόνων του πρωτοκόλλου IP, στο SDN παρέχεται η δυνατότητα να χρησιμοποιηθούν πολιτικές δρομολόγησης βάσει των απαιτήσεων του κάθε πελάτη και των αναγκών του δικτύου. Τα δίκτυα γίνονται προγραμματίσιμα και διαχειρίσιμα κάνοντας την υποδομή διαφανή για τις εφαρμογές και υπηρεσίες που παρέχουν, ενώ διευκολύνεται και η κατανομή πόρων, η κλιμακωσιμότητα στα κατανεμημένα κέντρα δεδομένων και η εικονικοποίηση των συσκευών που είναι απαραίτητη για περιβάλλοντα Cloud. [1] [2] 17

2.1 Αρχιτεκτονική SDN Υπάρχουν τρεις βασικές δομές στο SDN, το επίπεδο εφαρμογών, το επίπεδο ελέγχου και το επίπεδο δεδομένων. Στο επίπεδο εφαρμογών ανήκουν οι εφαρμογές που μέσω της NorthBound SDN διεπαφής εκφράζουν στο επίπεδο ελέγχου, δηλαδή στον SDN ελεγκτή, τις ανάγκες του δικτύου. Στο επίπεδο δεδομένων ανήκουν οι δικτυακές συσκευές κι εκεί λαμβάνεται χώρα η προώθηση των πακέτων με τρόπο που έχει ορίσει το επίπεδο ελέγχου. Στην παρακάτω εικόνα φαίνεται αναλυτικά η αρχιτεκτονική του SDN. [3] Εικόνα 1: Επισκόπηση Αρχιτεκτονικής των Software Defined Networks 18

2.1.1 Επίπεδο Εφαρμογών (SDN Application) Πρόκειται για προγράμματα μέσω των οποίων ο διαχειριστής του δικτύου μπορεί άμεσα να επικοινωνήσει με τον ελεγκτή ώστε να μάθει τις απαιτήσεις του δικτύου και να ορίσει την απαιτούμενη συμπεριφορά που πρέπει να εφαρμοστεί στο δίκτυο. 2.1.2 Επίπεδο Ελέγχου (SDN Controller) Η πλατφόρμα ελέγχου περιλαμβάνει στην ουσία τον SDN ελεγκτή που αποτελεί μια λογικά κεντρικοποιημένη ενότητα. Σε φυσικό επίπεδο ο ελεγκτής μπορεί να είναι κατανεμημένος σε διαφορετικά φυσικά μηχανήματα προκειμένου να υπάρχει κλιμακωσιμότητα και βελτιστοποίηση των διεργασιών. Ωστόσο, ο ελεγκτής συμπεριφέρεται ως μοναδική λογική μονάδα, με δικό της λειτουργικό σύστημα λαμβάνοντας ενιαίες αποφάσεις. Αρχικά λαμβάνει τις απαιτήσεις του συστήματος -δηλαδή του επιπέδου ελέγχου- και τις μεταφέρει στο επίπεδο δεδομένων κι αντίστοιχα αντιλαμβάνεται τυχόν αλλαγές στη λειτουργία του δικτύου -επίπεδο δεδομένων- και ενημερώνει το επίπεδο εφαρμογών. Αποτελείται στην ουσία από τους NorthBound Agents που συντελούν στην επικοινωνία του ελεγκτή με το επίπεδο εφαρμογών, την κεντρική μονάδα ελέγχου που είναι υπεύθυνη για τις διεργασίες που λαμβάνουν χώρα για τη λήψη αποφάσεων, καθώς και από CDPI (Control to Data-Plane Interface) Drivers που είναι υπεύθυνοι για τη σωστή επικοινωνία με το επίπεδο δεδομένων. 2.1.3 Επίπεδο Δεδομένων (SDN Datapath) Αποτελεί μια δικτυακή λογική οντότητα που παρέχει εποπτεία κι έλεγχο των διαδικασιών προώθησης και επεξεργασίας δεδομένων που λαμβάνουν χώρα στο δίκτυο. Αποτελείται από έναν CDPI Agent προκειμένου να επιτυγχάνεται η επικοινωνία με τον ελεγκτή και από ένα σύνολο συσκευών υπεύθυνων για την προώθηση της κίνησης καθώς και τις αντίστοιχες μεθόδους. 19

Το επίπεδο δεδομένων -αν και συμπεριφέρεται ως ενιαία ενότητα- δύναται να αποτελείται από κατανεμημένες φυσικές συσκευές με διαμοιραζόμενους πόρους, ενώ μπορεί να λειτουργήσει και με συσκευές που δεν είναι SDN. 2.1.4 NorthBound SDN Διεπαφή (SDN NorthBound Interfaces NBI) Πρόκειται για διεπαφές που είναι υπεύθυνες για την επικοινωνία του επιπέδου εφαρμογών με το επίπεδο ελέγχου. Παρέχουν αφενός άποψη του δικτύου στο επίπεδο εφαρμογών και αφετέρου τη δυνατότητα άμεσης παρέμβασης στις απαιτήσεις του δικτύου. 2.1.5 Διεπαφή διασύνδεσης επιπέδου ελέγχου-δεδομένων (SDN Control to Data-Plane Interface CDPI) Αποτελεί τη διεπαφή που είναι υπεύθυνη για την επικοινωνία του ελεγκτή με το επίπεδο δεδομένων. Παρέχει προγραμματιστικό έλεγχο όλων των λειτουργιών προώθησης των δεδομένων, αναφορά για τα στατιστικά της κίνησης στο δίκτυο καθώς και ενημέρωση του ελεγκτή σε περίπτωση κάποιας αλλαγής ή προβλήματος στο δίκτυο. 2.1.6 Διαχείριση (Management & Admin) Δεν αποτελεί μέρος της Αρχιτεκτονικής του SDN αλλά αποτελεί ουσιαστικά το λόγο ανάπτυξης των SDN, δηλαδή τον έλεγχο που μπορεί πλέον να εφαρμοστεί στα δίκτυα που υποστηρίζουν SDN. Βρίσκεται έξω από τις εφαρμογές, το επίπεδο ελέγχου και δεδομένων των SDN. Μέσω του επιπέδου εφαρμογών ο διαχειριστής μπορεί να ενημερωθεί για το δίκτυο ορίζοντας κατάλληλες συμπεριφορές. Όλη αυτή η επικοινωνία των εφαρμογών και του διαχειριστή, γίνεται με τη βοήθεια του ελεγκτή. 20

2.2 Το πρωτόκολλο OpenFlow Το OpenFlow είναι το πρώτο προτυποποιημένο πρωτόκολλο για την επικοινωνία του επιπέδου ελέγχου με το επίπεδο δεδομένων σε SDN αρχιτεκτονικές. Επιτρέπει την άμεση πρόσβαση και διαχείριση της πλατφόρμας προώθησης των δεδομένων των δικτυακών συσκευών, δηλαδή των εικονικών και φυσικών μεταγωγέων και δρομολογητών. Το OpenFlow είναι απαραίτητο για τη μετακίνηση του ελέγχου του δικτύου από τις δικτυακές συσκευές σε ένα λογικά κατανεμημένο λογισμικό ελέγχου και εφαρμόζεται και στις δυο πλευρές της διεπαφής μεταξύ του λογισμικού ελέγχου του SDN και της δικτυακής υποδομής. Το OpenFlow χρησιμοποιεί την έννοια της ροής (flow) για να αναγνωρίσει τη δικτυακή κίνηση και η οποία βασίζεται σε προκαθορισμένους κανόνες αντιστοίχισης που μπορούν στατικά ή δυναμικά να οριστούν από τον ελεγκτή. Επίσης επιτρέπει στον διαχειριστή να ορίσει πως θα κατανεμηθεί η κίνηση στις δικτυακές συσκευές ανάλογα τους πόρους του δικτύου, τις ανάγκες των εφαρμογών και τα πρότυπα της συνηθισμένης κίνησης στο δίκτυο. Ενώ στα παραδοσιακά IP δίκτυα η δρομολόγηση στο διαδίκτυο γίνεται βάσει των διευθύνσεων IP και δύο ροές με τα ίδια εναρκτήρια και τερματικά σημεία θα ακολουθήσουν την ίδια διαδρομή λόγω των ίδιων διευθύνσεων IP που έχουν, στην αρχιτεκτονική SDN δεν συμβαίνει το ίδιο. Πλέον δύο ροές μπορεί να έχουν ίδια σημεία πηγής και προορισμού αλλά να ακολουθούν άλλη διαδρομή και με διαφορετική προτεραιότητα διότι έχουν διαφορετικές απαιτήσεις, οπότε ο πάροχος να επιθυμεί διαφορετική πολιτική δρομολόγησης για την καθεμία. Δίκτυα αρχιτεκτονικής SDN που υποστηρίζουν OpenFlow μπορούν να αναπτυχθούν σε ήδη υπάρχοντα δίκτυα. Οι συσκευές δικτύωσης μπορούν να υποστηρίξουν προώθηση βάσει του OpenFlow όσο και βάσει της συμβατικής δρομολόγησης TCP/IP. Υπάρχει η δυνατότητα υβριδικών μεταγωγέων που λειτουργούν σε κάθε περιβάλλον (SDN ή μη) ή εφαρμόζουν κεντρικοποιημένο έλεγχο στις εφαρμογές (παρακολούθηση και διαχείριση του δικτύου), οπότε δεν απαιτείται να αντικαταστηθεί κάθε δικτυακή συσκευή με SDN-μεταγωγείς. [4] Αυτό είναι μεγάλο πλεονέκτημα για τους παρόχους που μπορούν να οδηγηθούν στην αρχιτεκτονική SDN σταδιακά, βασιζόμενοι στα παραδοσιακά δίκτυα τους μετατρέποντάς τα σε SDN. 21

2.3 OpenFlow Μεταγωγέας (OpenFlow Switch) Ο OpenFlow μεταγωγέας αποτελείται από δύο μέρη: το switch-agent και την πλατφόρμα δεδομένων. Το switch-agent επικοινωνεί μέσω του OpenFlow πρωτοκόλλου με τον ελεγκτή καθώς και με την πλατφόρμα δεδομένων μέσω εσωτερικού κατάλληλου πρωτοκόλλου. Είναι υπεύθυνο στο να μεταφράζει τις εντολές του ελεγκτή σε κατάλληλη γλώσσα μηχανής και να τις στέλνει στην πλατφόρμα δεδομένων προκειμένου να της είναι κατανοητές. Επίσης αντίστοιχα λαμβάνει από την πλατφόρμα δεδομένων τυχόν ειδοποιήσεις και τις μετατρέπει σε OpenFlow μηνύματα κατανοητά από τον ελεγκτή και του τα προωθεί. Η πλατφόρμα δεδομένων αναλαμβάνει τη διαχείριση και προώθηση των πακέτων, ενώ ανάλογα την παραμετροποίηση ενδέχεται να στείλει πακέτα στο switch-agent για επεξεργασία. Περιλαμβάνει πίνακες ροής και ανάλογες δράσεις για κάθε ροή, οπότε τα πακέτα προωθούνται ανάλογα σε ποια ροή ανήκουν και σε ποιον κανόνα του πίνακα ροής θα αντιστοιχιστούν. [2] Εικόνα 2: Δομή OpenFlow Μεταγωγέα 22

3 OpenDaylight Controller Ο SDN ελεγκτής αποτελεί τη μονάδα ελέγχου του ευφυούς δικτύου, αντιπροσωπεύοντας το επίπεδο ελέγχου μετά το διαχωρισμό του από το επίπεδο δεδομένων. Είναι η πλατφόρμα που εποπτεύει και διαχειρίζεται τις ροές κίνησης μέσω του ελέγχου των δικτυακών συσκευών με τα southbound APIs και παράλληλα ενημερώνει και διαχειρίζεται τις εφαρμογές με τα northbound APIs. [5] Οι SDN ελεγκτές χρησιμοποιούν συνήθως το OpenFlow ή και το OVSDB πρωτόκολλο για την επικοινωνία τους με τις δικτυακές συσκευές. Επίσης υπάρχουν και άλλα πρωτόκολλα γι αυτήν την επικοινωνία, το NetConf και το Yang. Στην παρούσα διπλωματική επιλέχθηκε ο OpenDaylight SDN ελεγκτής. Ο OpenDaylight ελεγκτής αναπτύχθηκε από την κοινότητα Linux Foundation και αποτελεί το μεγάλο έργο Ανοικτού Λογισμικού σχετικά με το Software Defined Networking. Ο κώδικάς του είναι γραμμένος σε γλώσσα JAVA και δύναται να επεκταθεί ως προς τις λειτουργίες του. Μεγάλες εταιρίες του κλάδου όπως οι Cisco, Brocade, Juniper Networks, IBM, Vmware, Ericsson, Microsoft, Big Switch Networks καθώς και ανεξάρτητοι μηχανικοί στα πλαίσια του Ανοικτού Λογισμικού δουλεύουν επίσης για να συμβάλουν στην ανάπτυξη του OpenDaylight project. Ο OpenDaylight υποστηρίζει το OpenFlow πρωτόκολλο καθώς και άλλα πρωτόκολλα και τεχνολογίες SDN αρχιτεκτονικής εφόσον μπορεί να παραμετροποιηθεί καταλλήλως από τον διαχειριστή. [6] [7] 23

3.1 Αρχιτεκτονική OpenDaylight Ο OpenDaylight ελεγκτής αποτελείται από τρία μέρη: Την πλατφόρμα του ελεγκτή Τις Northbound εφαρμογές και υπηρεσίες Τις Southbound επεκτάσεις και πρωτόκολλα Στην παρακάτω εικόνα φαίνονται τα στοιχεία του OpenDaylight στη νεότερη έκδοση του (Αύγουστος 2016), την Beryllium. Εικόνα 3: Επισκόπηση Αρχιτεκτονικής OpenDaylight Controller (Έκδοση Beryllium) [8] 24

3.2 Πλατφόρμα Ελεγκτή Η πλατφόρμα του ελεγκτή εμπεριέχει τόσο Northbound όσο και Southbound διεπαφή. Η Northbound διεπαφή παρέχει στον ελεγκτή υπηρεσίες καθώς και ένα σύνολο REST API εφαρμογών που μπορούν να χρησιμοποιηθούν για τη διαχείριση και την παραμετροποίηση της υποδομής του δικτύου. Η πρόσβαση στη Northbound διεπαφή του ελεγκτή είναι εφικτή μετά την επαλήθευση ταυτότητας και αδειοδότησης του χρήστη, όπως φαίνεται στο υψηλότερο επίπεδο της παραπάνω εικόνας. Η Southbound διεπαφή υλοποιεί πρωτόκολλα για τη διαχείριση και τον έλεγχο της δικτυακής υποδομής που βρίσκεται στο κατώτερο επίπεδο. Εδώ υλοποιούνται αρκετές επεκτάσεις είτε για την υποστήριξη δικτυακών πρωτοκόλλων είτε για την απευθείας επικοινωνία με το υλικό. Τα πιο γνωστά πρωτόκολλα που υλοποιούνται είναι τα OpenFlow, NetConf, SNMP, OVSDB. Η πλατφόρμα του ελεγκτή επικοινωνεί με το δίκτυο χρησιμοποιώντας τη Southbound διεπαφή και παρέχει βασικές δικτυακές υπηρεσίες μέσω ενός συνόλου λειτουργιών: Host Tracker, L2 Switch, OpenFlow Forwarding Rules Mgr, OpenFlow Stats Manager, OpenFlow Switch Manager, Topology Processing. 3.2.1 Βασικές Λειτουργίες Υπηρεσιών Δικτύωσης (Base Network Service Functions) Host Tracker Αποθηκεύει πληροφορίες για τα τερματικά του συστήματος (διευθύνσεις MAC, IP, τύπος μεταγωγέα, αριθμός θύρας) και παρέχει API για την ανάκτηση πληροφοριών γι αυτά. Δύναται να δουλέψει με στατικό ή δυναμικό τρόπο. Στατικώς, η βάση δεδομένων του Host Tracker μεταχειρίζεται χειροκίνητα μέσω Northbound APIs ενώ δυναμικώς ο Host Tracker χρησιμοποιεί το ARP πρωτόκολλο για να ανιχνεύσει τις πληροφορίες για τη βάση δεδομένων του. 25

L2 Switch Με την άφιξη ενός πακέτου, η λειτουργία αυτή μαθαίνει την MAC διεύθυνση της πηγής. Εάν γνωρίζει τον προορισμό, μεταφέρει το πακέτο στον προορισμό, διαφορετικά στέλνει broadcast μήνυμα (δηλαδή μήνυμα προς όλες τις συσκευές) σε όλες τις εξωτερικές πόρτες του δικτύου. OpenFlow Forwarding Rules Manager Διαχειρίζεται βασικούς κανόνες προώθησης, επιλύει τυχόν συγκρούσεις μεταξύ των κανόνων αυτών και τους επικυρώνει. Επικοινωνεί με Southbound επεκτάσεις φορτώνει OpenFlow κανόνες στους διαχειριζόμενους μεταγωγείς. OpenFlow Statistics Manager Υλοποιεί τη συλλογή στατιστικών αποστέλλοντας αιτήσεις για στατιστικά σε όλους τους ενεργούς κόμβους (δηλαδή τους διαχειριζόμενους μεταγωγείς) του ευφυούς δικτύου και αποθηκεύει τις απαντήσεις τους στο operational πεδίο. Επίσης επιστρέφει πληροφορίες στο Northbound API για τα εξής: node-connector (την πόρτα του συνδεόμενου μεταγωγέα) flow meter table group statistics OpenFlow Switch Manager Παρέχει πληροφορίες για τους κόμβους (μεταγωγείς) τους ευφυούς δικτύου καθώς και τις πόρτες στις οποίες συνδέονται. Όσο ο ελεγκτής ανακαλύπτει νέα δικτυακά στοιχεία, οι 26

πληροφορίες γι αυτά αποθηκεύονται στο δέντρο δεδομένων του Switch Manager. Μπορεί να χρησιμοποιηθεί το Northbound API για την ανάκτηση των πληροφοριών αυτών. Topology Processing Αποθηκεύει και μεταχειρίζεται πληροφορίες σχετικά με τις διαχειριζόμενες δικτυακές συσκευές. Όταν ο ελεγκτής εκκινείται, ο Topology Manager δημιουργεί τον κεντρικό κόμβο της τοπολογίας. Έκτοτε ενημερώνεται για την τοπολογία, για τυχόν ειδοποιήσεις και αλλαγές σ αυτό το δέντρο, συμπεραλαμβανομένων όλων των μεταγωγέων που έχουν ανακαλυφθεί. 3.3 MD-SAL (Model Driven-Service Abstraction Layer) Το MD-SAL παρέχει μια προσέγγιση που επιτρέπει την ενοποίηση των Southbound και Northbound APIs με τις δομές δεδομένων που χρησιμοποιούνται σε διάφορα στοιχεία του ελεγκτή. Στο MD-SAL, κάθε δεδομένο σχετιζόμενο με την κατάσταση λειτουργίας αποθηκεύεται σε μορφή DOM (Document Object Model), γνωστό ως δέντρο δεδομένων. Υπάρχουν δύο είδη δέντρου δεδομένων στον OpenDaylight ελεγκτή: Configuration : Χρησιμοποιείται για να αποθηκευτούν πληροφορίες που δεν θα διαγραφτούν μετά και την επανεκκίνηση του ελεγκτή. Επίσης αποθηκεύονται παραμετροποιήσεις που στέλνονται στον ελεγκτή μέσω του REST API Operational : Εδώ ο ελεγκτής αποθηκεύει προσωρινές πληροφορίες που προκύπτουν κατά την εκτέλεση των διεργασιών στο δίκτυο, καθώς και πληροφορίες που ο ελεγκτής ανακάλυψε από το Configuration πεδίο δεδομένων 27

Εικόνα 4: Αλληλεπίδραση μεταξύ του ελεγκτή και της Southbound επέκτασης Όταν ο μεταγωγέας προσπαθεί να εγγραφτεί στα στοιχεία του ελεγκτή, πρώτα εγγράφεται στην Southbound επέκταση η οποία προκαλεί μια ειδοποίηση της μεθόδου NodeUpdated. Μετά τη λήψη της ειδοποίησης: Ο Inventory Manager προσθέτει το νέο κόμβο (μεταγωγέα) στο operational δέντρο δεδομένων. Ο Statistics Manager παίρνει τις ανανεωμένες πληροφορίες από τη βάση δεδομένων inventory μέσα από συναλλαγές ανάγνωσης στο operational δέντρο δεδομένων. Ο Topology Manager ανανεώνει την αντίστοιχη τοπολογία στο DOM υπόδεντρο. 28

3.4 REST API Το REST (Representational State Transfer) αποτελεί αρχιτεκτονική που χρησιμοποιείται σε διαδικτυακές εφαρμογές (WEB development). Τα συστήματα που σχεδιάζονται σε REST αρχιτεκτονική έχουν καλή επίδοση, αξιοπιστία και δυνατότητα κλιμακωσιμότητας ως προς το πλήθος των χρηστών που μπορούν σταδιακά να υποστηρίξουν. Τα RESTful συστήματα επικοινωνούν συνήθως μέσω του HTTP πρωτοκόλλου μέσω των μεθόδων GET, PUT, POST, DELETE τις οποίες χρησιμοποιεί συνήθως το πρόγραμμα περιήγησης για να ανακτήσει και να στείλει δεδομένα σε απομακρυσμένους εξυπηρετητές. [9] Επίσης, εκτός του προγράμματος περιήγησης, δύναται να ανακτηθούν πληροφορίες και αποσταλούν παραμετροποιήσεις σε RESTful συστήματα μέσω ενός τερματικού και συγκεκριμένα της bash εντολής curl, συνοδευόμενη με τα κατάλληλα ορίσματα (username, κωδικό, URI). Στην περίπτωση που αποστέλλονται παραμετροποιήσεις, μέσω του curl μπορεί κάποιος να στείλει το κατάλληλο κείμενο σε μορφή json ή xml. Οι πληροφορίες που επιστρέφονται από το σύστημα είναι επίσης σε json ή xml μορφή. Τα πλεονεκτήματα της REST αρχιτεκτονικής σε σχέση με παρόμοιες (όπως η SOAP) είναι : Μπορεί να αξιοποιηθεί η cache μνήμη Πρόκειται για stateless πρωτόκολλο, δηλαδή υπάρχει ανεξαρτησία μεταξύ της κάθε αίτησης πελάτη και αντίστοιχης απάντησης Αξιοποιείται ένα πολυεπίπεδο σύστημα Αξιοποιείται μια ενιαία διεπαφή [10] Το πρωτόκολλο της REST αρχιτεκτονικής είναι το RESTCONF. Το RESTCONF επιτρέπει πρόσβαση σε δομές δεδομένων στον ελεγκτή. Όπως έχει περιγραφτεί και στο MD-SAL, υπάρχουν δύο ειδών δομές δεδομένων: Config: Περιέχει τις πληροφορίες που προστίθενται μέσω του ελεγκτή 29

Operational: Περιέχει τις πληροφορίες που προστίθενται μέσω του δικτύου Ο OpenDaylight έχει REST αρχιτεκτονική οπότε μπορεί να προσφέρει τα παραπάνω. Κάθε αίτηση που του γίνεται μέσω HTTP μεθόδου, πρέπει να γίνεται στο αντίστοιχο URI, που έχει τη μορφή : http://<odl-ip>:8181/restconf/operational/<path>/ http://<odl-ip>:8181/restconf/config/<path>/ 3.5 Εκκίνηση OpenDaylight Για την εγκατάσταση του ελεγκτή είναι απαραίτητη η λήψη της αντίστοιχης έκδοσης καθώς και η ύπαρξη των κατάλληλων βιβλιοθηκών JAVA στο μηχάνημα ως: root@odl: ~# sudo apt-get install maven openjdk-7-jdk openjdk-7-jre root@odl: ~# export JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk-amd64 Εικόνα 5: Εκκίνηση του OpenDaylight 30

3.6 DLUX Ο OpenDaylight ελεγκτής δίνει τη δυνατότητα γραφικής αναπαράστασης του δικτύου καθώς και παραμετροποίησής του με gui, εκτός από προγραμματιστικά μέσω του REST API. Μέσω του περιηγητή στο : http://<odl-ip>:8181/index.html#/topology προκύπτει η εξής απεικόνιση ευφυούς δικτύου Εικόνα 6: Γραφική απεικόνιση τοπολογίας του OpenDaylight μέσω του DLUX 31

32

4 Mininet Το Mininet είναι ένας εξομοιωτής δικτύων που σε έναν Linux πυρήνα μπορεί να εκτελεί και να προσομοιάζει τη λειτουργία εικονικών τερματικών, μεταγωγέων, ελεγκτών και γραμμών. Τα τερματικά στο Mininet τρέχουν Linux λειτουργικό σύστημα και συμπεριφέρονται σαν πραγματικές συσκευές στις οποίες μπορεί να γίνει σύνδεση με ssh (δικτυακό πρωτόκολλο για την ασφαλή μεταφορά δεδομένων) και να γίνει εκτέλεση προγραμμάτων. Τα πακέτα που μεταφέρονται για την εκτέλεση των προγραμμάτων περνούν από διεπαφές Ethernet με χωρητικότητα γραμμής που μπορεί να παραμετροποιηθεί [11]. Οι μεταγωγείς υποστηρίζουν το πρωτόκολλο OpenFlow για υψηλή ευελιξία σε παραμετροποίηση της δρομολόγησης σε Software Defined Networking αρχιτεκτονικές. [12] Το Mininet έχει ευρεία χρήση από τους μηχανικούς δικτύων για την ανάπτυξη προγραμμάτων και μελέτη των αποτελεσμάτων τους για τους εξής λόγους: Δύναται να δημιουργήσει όποια τοπολογία επιθυμεί με ένα απλό Python script. Είναι γρήγορο και η έναρξη της λειτουργίας του δικτύου είναι άμεση. Είναι έργο Ανοικτού Λογισμικού, που σημαίνει πως μπορεί ο καθένας να συνεισφέρει σε αυτό αλλά και να το παραμετροποιήσει όπως θέλει. Υποστηρίζει το OpenFlow πρωτόκολλο κι αποτελεί απλό και οικονομικό τρόπο για πειράματα σε δίκτυα SDN. Μπορεί επομένως κανείς στο Mininet να παραμετροποιήσει την προώθηση πακέτων εφόσον οι μεταγωγείς είναι προγραμματίσιμοι με το OpenFlow Μπορεί να τρέξει πραγματικά προγράμματα εφόσον μπορεί να εκτελέσει ό,τι εκτελείται σε Linux και να μεταφέρει αυτά τα προγράμματα σε πραγματικές συσκευές στη συνέχεια Δίνει τη δυνατότητα CLI (Command Line Interface) για debugging και εντολές για πειραματισμό στο δίκτυο 33

Το βασικότερο πλεονέκτημα κατά την προσομοίωση δικτύων στο Mininet είναι πως ο κώδικας που αναπτύσσεται για τους OpenFlow μεταγωγείς και τις υπόλοιπες δικτυακές συσκευές μπορεί να εκτελεστεί σε πραγματικό σύστημα με ελάχιστες αλλαγές. Επομένως ο διαχειριστής μπορεί να χρησιμοποιήσει το Mininet για τον γρήγορο έλεγχο της εφαρμογής του, κι εφόσον είναι έτοιμη, να την εκτελέσει σε πραγματικό δίκτυο. 4.1 Έναρξη Τοπολογίας στο Mininet Στη συνέχεια θα παρουσιαστεί ένα απλό παράδειγμα τοπολογίας στο Mininet. from mininet.topo import Topo class MyTopo( Topo ): def init ( self ): # Initialize topology Topo. init ( self ) host1 = self.addhost( 'h1', ip='192.168.1.101/24', mac='ca:c4:d7:e5:0a:01' ) host2 = self.addhost( 'h2', ip='192.168.1.102/24', mac='ca:c4:d7:e5:0a:02' ) host3 = self.addhost( 'h3', ip='192.168.1.103/24', mac='ca:c4:d7:e5:0a:03' ) switch1= self.addswitch( 's1') switch2= self.addswitch( 's2' ) switch3= self.addswitch( 's3') switch4= self.addswitch( 's4') # Add links self.addlink( host1, switch1 ) self.addlink( host2, switch2 ) self.addlink( host3, switch3 ) self.addlink( switch4, switch1 ) self.addlink( switch4, switch2 ) self.addlink( switch4, switch3 ) topos = { 'mytopology': ( lambda: MyTopo() ) } 34

Topo: Η βασική κλάση για τις τοπολογίες στο Mininet addhost: προσθέτει ένα τερματικό στην τοπολογία. Η διεύθυνση IP και MAC που τέθηκαν ως ορίσματα, είναι προαιρετικά addswitch: προσθέτει έναν μεταγωγέα στην τοπολογία addlink: προσθέτει μια αμφίδρομη γραμμή στην τοπολογία μεταξύ των δύο συσκευών που έχουν τεθεί ως ορίσματα. Μπορούν επίσης να τεθούν κι άλλα ορίσματα όπως η χωρητικότητα της γραμμής, η καθυστέρηση και ο μέγιστος αριθμός πακέτων στην ουρά αναμονής. Για την εκτέλεση του παραπάνω script στο Mininet, εκτελείται η εντολή: sudo mn --custom topo.py --topo topology --controller=remote, ip=<odl-ip> Όπου καθορίζεται η τοπολογία που θα τρέξει, η ονομασία του script στο οποίο βρίσκεται καθώς και η σύνδεση της τοπολογίας με τον ελεγκτή μέσω της διεύθυνσής του. Εικόνα 7: Παράδειγμα τοπολογίας στο Mininet 35

36

5 Data Centers Τα κέντρα δεδομένων είναι χώροι με υψηλής κλίμακας υπολογιστικά συστήματα που περιέχουν IT υλικοτεχνικό εξοπλισμό όπως εξυπηρετητές (servers) για επεξεργασία δεδομένων, συσκευές αποθήκευσης δεδομένων και συσκευές δικτύωσης για την επικοινωνία εντός και εκτός του κέντρου. Επίσης τα Data Centers περιέχουν εξοπλισμό για τη λειτουργία της υποδομής, όπως συσκευές για την ηλεκτροδότηση των μηχανημάτων καθώς και hardware για την ανάκτηση δεδομένων σε περίπτωση βλάβης. Για τη σωστή και αδιάκοπη λειτουργία όλων αυτών των συσκευών απαιτείται επίσης και εξοπλισμός για τη διατήρηση κατάλληλων συνθηκών περιβάλλοντος (θερμοκρασίας και υγρασίας). [13] Η λειτουργία των αναφερθέντων μηχανημάτων συνιστούν τα κέντρα δεδομένων ως μια σημαντική υποδομή σε κατανάλωση ηλεκτρικής ενέργειας. Επίσης, αποθηκεύουν δεδομένα που μπορεί ανά πάσα στιγμή να χρειαστούν ανάκτηση λόγω της αίτησης πελάτη, οπότε πρέπει οι συσκευές να βρίσκονται πάντα σε ετοιμότητα, είτε υπάρχουν αιτήσεις από πελάτες είτε όχι. Η λειτουργία τους είναι αδιάκοπη λοιπόν. Οι περισσότερες και μεγαλύτερες επιχειρήσεις (όπως Facebook, Google, Amazon) κάνουν χρήση cloud computing, το οποίο απαιτεί την ύπαρξη Data Centers για την κατανεμημένη και αδιάλειπτη αποθήκευση, ανάκτηση και επεξεργασία δεδομένων. Ομοίως και η ανάγκη για μεγαλύτερη χρήση του διαδικτύου -λόγω της αύξησης των χρηστών και των ευφυών συσκευών- καθώς και οι ηλεκτρονικές συναλλαγές που τείνουν να αντικαταστήσουν τις παλιότερες μεθόδους, καθιστούν τα Data Centers, το νέο βασικό άξονα για την ανάπτυξη της οικονομίας αλλά και το νέο αναπτυσσόμενο πεδίο μελέτης για του επιστήμονες. Τόσο για τη βελτιστοποίηση των λειτουργιών των Data Centers, όσο και για την εύρεση τρόπων για την εξοικονόμηση ενέργειας για την ηλεκτροδότηση τους, αφού αναμένεται στο μέλλον να παίξουν καθοριστικό ρόλο στην αποφυγή των καταστροφών λόγω της υπερθέρμανσης του πλανήτη. Για την Αμερική συγκεκριμένα -στην οποία λειτουργούν οι μεγαλύτερες εταιρίες που κάνουν χρήση των Data Centers- υπολογίζεται πως σε ένα έτος καταναλώθηκαν πάνω από 90 δις kwh για τη λειτουργία των Data Centers. Εκτιμάται δε, πως η κατανάλωση αυτή μέχρι το 2020 θα αυξάνεται σε ρυθμούς 7% κάθε χρόνο και θα αγγίξει 37

τα 140 δις kwh ετησίως ή 13 δις $ κόστος σε κατανάλωση αυτού του ρεύματος, μόνο για την Αμερική. Για τον πλανήτη τα ποσά αυτά σημαίνουν καύση περίπου 150 τόνων άνθρακα, που καθιστά τεράστια οικολογική επιβάρυνση και εντείνουν την ανάγκη εύρεσης τρόπων για τον περιορισμό αυτής της κατανάλωσης. 5.1 Άλλοι μέθοδοι εξοικονόμησης ενέργειας Έχουν ήδη γίνει μελέτες που να κινούνται σε αυτό το επίπεδο, στην ελάττωση της ηλεκτρικής ενέργειας που απαιτείται για τη λειτουργία των Data Centers, και συνεπώς στην προστασία του πλανήτη. Είναι πραγματικότητα μάλιστα, πως ενώ οι συσκευές συνεχίζουν να κοστίζουν λιγότερο ακολουθώντας το νόμο του Moore, το ηλεκτρικό ρεύμα τείνει να γίνει ακριβότερο και υπολογίζεται ότι θα κοστίζει 140 / Mwh το 2020 από τα 110 / Mwh που στοίχιζε το 2010. [14] Η μεγαλύτερη πρόοδος έχει γίνει πάνω στην επάρκεια και αποτελεσματικότητα του εξοπλισμού προκειμένου να ελαττωθεί ο χρόνος αδρανοποίησης τους. Πρόβλημα αποτελεί ωστόσο η χρησιμοποίηση των εξυπηρετητών και το γεγονός πως βρίσκονται διαρκώς σε ετοιμότητα χωρίς συχνά να παρέχουν κάποιο έργο στην εξυπηρέτηση αιτήσεων πελατών. Ο μέσος εξυπηρετητής που λειτουργεί, προσφέρει μόνο το 12-18% των δυνατοτήτων του, σε χωρητικότητα και λειτουργίες, παραμένοντας ενεργός διαρκώς και καταναλώνοντας ενέργεια εν αναμονή λήψης δεδομένων ή αίτησης για κάποια συναλλαγή. Φτάνοντας σε υψηλά ποσοστά χρησιμοποίησης των εξυπηρετητών -άνω του 50% -, θα αυξανόταν το κόστος εγκατάστασης αλλά το κόστος αυτό μπορεί να αντισταθμιστεί με το κέρδος από την εξοικονόμηση ενέργειας που θα μπορούσε να επιτευχθεί. Όσο λιγότερο χρησιμοποιείται ο εξυπηρετητής για κάποια λειτουργία, τόσο περισσότερο μειώνεται η αποτελεσματικότητά του, ενώ καταναλώνει ρεύμα. Με την ίδια κατανάλωση ρεύματος, θα μπορούσαν να γίνουν πολλαπλάσιες συναλλαγές αν 38

αντιμετωπιζόταν το πρόβλημα της χαμηλής χρησιμοποίησης των εξυπηρετητών, που αποτελεί και το μείζον θέμα που ασχολούνται οι ερευνητές για την ελάττωση των εκπομπών στο περιβάλλον λόγω της ηλεκτροδότησης των Data Centers. Εκτός αυτού, υπάρχουν εξυπηρετητές που δεν παρέχουν καμία απολύτως λειτουργικότητα αλλά παραμένουν στο σύστημα καταναλώνοντας ενέργεια 24 ώρες τη μέρα αδιαλείπτως, οι λεγόμενοι comatose servers. Οι comatose ή αλλιώς zombie servers προκύπτουν συνήθως μετά το πέρας ή την αλλαγή κάποιου έργου ή και λόγω της έλλειψης ενδιαφέροντος των χρηστών για την εφαρμογή για την οποία χρησιμοποιούνταν ο server. Οι εξυπηρετητές αυτοί αποτελούν συνήθως το 20-30% των εξυπηρετητών κάθε Data Center. Επομένως ένας τρόπος εξοικονόμησης ενέργειας είναι η απομάκρυνση και αντικατάσταση αυτών των ανενεργών εξυπηρετητών. Το πρόβλημα είναι πως συχνά οι διαχειριστές των Data Centers δεν γνωρίζουν τους ιδιοκτήτες των εξυπηρετητών, γι αυτό και είναι δύσκολο να δώσουν την έγκριση για την απομάκρυνση των ανενεργών, με επιφύλαξη μήπως δημιουργήσουν πρόβλημα σε κάποιο σημαντικό έργο. Το ποσοστό των εξυπηρετητών που συνήθως οι διαχειριστές δεν γνωρίζουν σε ποιον ανήκουν ανέρχεται σε 15-30%. Μία ακόμη καινοτομία που μπορεί να βοηθήσει τους διαχειριστές των Data Centers να ελαττώσουν την κατανάλωσή τους σε ρεύμα είναι η επέκταση της τεχνικής της Εικονικοποίησης (Virtualization). Η τεχνική αυτή επιτρέπει τη δημιουργία εικονικών μηχανημάτων, όπως hardware, συσκευών δικτύωσης, μνήμης και λειτουργικών συστημάτων. Ενώ παλιότερα μπορούσε να εγκαταστηθεί μόνο ένα λειτουργικό σύστημα σε έναν υπολογιστή, τώρα στα εικονικά μηχανήματα μπορούν να λειτουργήσουν πολλά λειτουργικά συστήματα στο ίδιο μηχάνημα. Πλέον μπορούν να λειτουργήσουν πολλοί εικονικοί εξυπηρετητές πάνω σε έναν φυσικό εξυπηρετητή, οπότε επενδύοντας σε λιγότερα φυσικά μηχανήματα μπορούν να έχουν οι εταιρίες τις ίδιες υπηρεσίες με παλιότερα. Αυτό αποφέρει μείωση των εξόδων, ελάττωση των μηχανημάτων τόσο για τις διεργασίες των Data Centers όσο και την υποστήριξή του (συστήματα διατήρησης συνθηκών περιβάλλοντος) και επομένως σημαντική ελάττωση στην κατανάλωση ενέργειας. Ωστόσο η Εικονικοποίηση δεν έχει πάρει ακόμα τις διαστάσεις που θα μπορούσε να έχει, αφού δεν έχουν αντικαταστηθεί πλήρως τα μηχανήματα με εικονικά. 39

5.2 Εξοικονόμηση ενέργειας μέσω των δικτυακών συσκευών Ακόμα και αν τα μηχανήματα δικτύωσης στα Data Centers δεν καταναλώνουν τόση ενέργεια όσο οι εξυπηρετητές, εξακολουθούν να καταναλώνουν τεράστια ποσά ενέργειας, γι αυτό και οι Μηχανικοί Δικτύων προσανατολίζονται προς αυτήν την κατεύθυνση προκειμένου να βρουν τρόπους να ελαττώσουν τις εκπομπές από τα Data Centers προς το περιβάλλον. Πάνω στην ιδέα αυτή βασίζεται η παρούσα εργασία. Έχουν ήδη γίνει έρευνες σε ερευνητικά κέντρα του εξωτερικού πάνω στο Energy Aware Routing, δηλαδή στην εύρεση βέλτιστων μεθόδων δρομολόγησης για να εξοικονομηθεί ηλεκτρική ενέργεια στα Data Centers. Οι μέθοδοι αυτοί χρησιμοποιούν την τοπολογία του εκάστοτε δικτύου και την κίνηση του, και με τη βοήθεια ευριστικών μεθόδων καθορίζουν ποιες δικτυακές συσκευές υπολειτουργούν και θα πρέπει να απενεργοποιηθούν [15]. Σε αυτήν την κατεύθυνση κινείται η μέθοδος ElasticTree κατά την οποία ανάλογα το που υπάρχει μεγαλύτερο φορτίο στο δίκτυο, με ευριστικές, άπληστες και μεθόδους πρόβλεψης, βρίσκονται ποιες δικτυακές συσκευές (μεταγωγείς, δρομολογητές, γραμμές) πρέπει να απενεργοποιηθούν. Προκύπτει ένα Συνδετικό Δέντρο για τα τερματικά (εξυπηρετητές) μεν, αλλά που δεν περιλαμβάνει όλες τις συσκευές του δικτύου. Αυτή η μέθοδος είναι χρήσιμη σε περίπτωση χαμηλής κινητικότητας στο δίκτυο. Με τη μέθοδο αυτή υπολογίζεται ελάττωση της κατανάλωσης ενέργειας της τάξεως των 25-40%. [16] Παράλληλα, εκτός από ερευνητικά κέντρα του εξωτερικού, πραγματοποιούνται έρευνες και σε ελληνικά κέντρα. Συγκεκριμένα στο Εθνικό Μετσόβιο Πολυτεχνείο σε συνεργασία με το Εθνικό Δίκτυο Έρευνας & Τεχνολογίας (GRNET) μελετήθηκαν πολιτικές δρομολόγησης για ενεργειακή εξοικονόμηση που εκτιμάται πως μπορούν να εξοικονομήσουν πάνω από το 50% της ενέργειας που καταναλώνεται απενεργοποιώντας τις κατάλληλες δικτυακές συσκευές. Η διαφορά αυτών των μελετών από αυτές του εξωτερικού είναι πως επικεντρώθηκαν στην απενεργοποίηση γραμμών, δηλαδή μόνο των διεπαφών των 40

μεταγωγέων και όχι των ίδιων των συσκευών. Οι γραμμές καταναλώνουν συνολικά πάνω από το 70% της ενέργειας που χρειάζεται ο δρομολογητής. Το να απενεργοποιηθεί τελείως η συσκευή (όπως ορίζουν οι υπόλοιπες έρευνες) θα επέφερε μεγαλύτερα κέρδη εν μέρει, είναι πιο δύσκολο να εφαρμοστεί όμως γιατί ακόμα και οι δρομολογητές που ανήκουν στο backbone internet (οι βασικοί δρομολογητές για τη μεταφορά κίνησης στο διαδίκτυο), συχνά έχουν διεπαφές που συνδέονται με τοπικούς πελάτες και δεν μπορούν να απενεργοποιηθούν. Για τη εξαγωγή των αποτελεσμάτων λαμβάνονται υπόψιν η τοπολογία του δικτύου, η κίνηση πάνω στις γραμμές του -συγκεκριμένα το bandwidth από όλους τους μεταγωγείς-πηγής προς όλους τους μεταγωγείς-προορισμού καθώς και ενεργειακά στοιχεία για την κατανάλωση ρεύματος των συσκευών και τη χωρητικότητα των γραμμών. Ακόμα και για συσκευές που καταναλώνουν σχεδόν το μέγιστο της ενέργειας που θα μπορούσαν, σχεδόν το 50% από αυτήν την ενέργεια απαιτείται για τις γραμμές και αυτό θα μπορούσε να ελαττωθεί απενεργοποιώντας με ευφυή τρόπο τις σωστές διεπαφές. Η εξοικονόμηση αυτή κυμαίνεται στο 50% για τις ώρες που δεν υπάρχει πολλή κίνηση και φτάνει στο 70% τις ώρες αιχμής. Το τελευταίο ποσοστό μπορεί να αγγίξει το 95% αν χρησιμοποιηθούν ενεργειακές συσκευές με γραμμική κατανάλωση ως προς την κίνηση στο δίκτυο. Ο αλγόριθμος που μελετήθηκε είναι υπεύθυνος για την εύρεση των διεπαφών που θα πρέπει ευφυώς να απενεργοποιηθούν προκειμένου να υπάρξει βέλτιστη δρομολόγηση στο δίκτυο, και είναι ευθύνη του διαχειριστή συστήματος στη συνέχεια να αυτοματοποιήσει τη διαδικασία και να ενεργοποιήσει/ απενεργοποιήσει τις κατάλληλες διεπαφές. [17] Ο αλγόριθμος που μελετήθηκε γράφτηκε σε CPLEX με τη βοήθεια του mixed integer programming. 41

42

6 Ανάπτυξη εφαρμογής ελέγχου του δικτύου Η αύξηση των χρηστών του διαδικτύου, η διαπίστωση πως οι περισσότεροι συνδέονται στο διαδίκτυο με περισσότερες από μία συσκευές, καθώς και η ανάγκη των επιχειρήσεων για υποστήριξή τους από κέντρα δεδομένων (data centers) έχουν καταστήσει το διαδίκτυο ως το πλέον απαραίτητο εργαλείο για όλους. Αυτή η έκρηξη της χρήσης του όμως έχει δημιουργήσει πολλά ερωτήματα για το κατά πόσο τα μηχανήματα που είναι απαραίτητα για τη λειτουργία του καταναλώνουν ενέργεια με συνετό και οικολογικό τρόπο. Από έρευνες που διεξήχθησαν το 2011, υπολογίζεται πως για τη λειτουργία του διαδικτύου καταναλώνονται 84 με 143 GigaWatt ηλεκτρικής ενέργειας κάθε χρόνο, ή περίπου το 3.6% - 6.2% της συνολικής ενέργειας παγκοσμίως [16]. Πολύ μεγάλο μέρος αυτού του ποσοστού ενέργειας καταναλώνεται στα data centers. Είναι ευκαιρία λοιπόν τώρα με την καινοτομία και την εξάπλωση του SDN, να εκμεταλλευτούμε τη δυνατότητα του κεντρικού απομακρυσμένου ελέγχου που μας δίνει και να προωθήσουμε πολιτικές δρομολόγησης με σκοπό την εξοικονόμηση ενέργειας στα δίκτυα νέας γενιάς που έρχονται στο προσκήνιο. Η ιδέα είναι η δημιουργία μιας εφαρμογής -σε ρόλο διαχειριστή δικτύου- που επικοινωνεί εξωτερικά με τον ελεγκτή και υλοποιεί έναν μηχανισμό συλλογής στατιστικών τα οποία αποτελούν τα απαραίτητα στοιχεία για την εύρεση αποδοτικής πολιτικής δρομολόγησης μέσω κατάλληλου αλγορίθμου. 43

6.1 Απαιτούμενα εργαλεία 6.1.1 Λογισμικό CPLEX Έχει αναπτυχθεί από την IBM ένα πακέτο λογισμικού για βελτιστοποιήσεις, κατάλληλο για επίλυση προβλημάτων γραμμικού προγραμματισμού, το IBM ILOG CPLEX Optimization Studio ή εν συντομία CPLEX. Το CPLEX ενδείκνυται για προβλήματα απόφασης δίνοντας τη δυνατότητα για διευκόλυνση των πράξεων και συνεπώς για μικρότερους χρόνους εκτέλεσης. Συγκεκριμένα δίνει τη δυνατότητα επεξεργασίας απαιτητικών προβλημάτων σε κατανεμημένα συστήματα μέσω παράλληλων αλγορίθμων. Και στη δική μας περίπτωση γίνεται εκτέλεση του προγράμματος σε παράλληλα νήματα διότι για πολύ μεγάλα δίκτυα η επεξεργασία των στοιχείων ήταν χρονοβόρα και αυτό καθυστερούσε τη λήψη απόφασης για την αλλαγή κατάστασης των γραμμών του δικτύου. [18] Η εκτέλεση προγραμμάτων στο CPLEX απαιτεί την εγκατάσταση του αντίστοιχου πακέτου της IBM και πραγματοποιείται στο unix shell μέσω της bash εντολής oplrun. Οπότε η ενσωμάτωση του αλγορίθμου βέλτιστης ενεργειακά δρομολόγησης με τις διαχειριστικές εντολές του ελεγκτή στο ευφυές δίκτυο, ήταν εφικτή. 6.1.2 Η βιβλιοθήκη jq Όλες οι πληροφορίες που χρειάστηκαν από τον ODL, κατέβηκαν στη μορφή json (εναλλακτικά θα μπορούσε να είχε χρησιμοποιηθεί και xml). Για τη μορφοποίηση των πολύ μεγάλων αρχείων, την επεξεργασία και τη μαζική εξαγωγή συγκεκριμένων στοιχείων χρησιμοποιήθηκε η εντολή jq, που αποτελεί ουσιαστικά ένα φίλτρο για json αρχεία. Συνέβαλε τόσο απ την πρακτική μεριά της εφαρμογής όσο και στη βελτιστοποίηση της από άποψη χρόνου και χώρου. 44

6.1.3 Απαιτήσεις OpenDaylight Κατά τη μελέτη του ελεγκτή OpenDaylight για την εκπόνηση αυτής της διπλωματικής εργασίας, ανανεώθηκαν οι εκδόσεις του. Αρχικά έγινε χρήση της έκδοσης Lithium, ενώ στη συνέχεια έγινε εγκατάστασης της τελευταίας έκδοσης Beryllium για τυχόν αναβαθμίσεις. Για να τρέξει ο ελεγκτής θα πρέπει να γίνει εγκατάσταση κάποιων επεκτάσεων (features) προκειμένου να υποστηριχτεί η μέθοδος l2switch, το mdsal μοντέλο, το restconf πρωτόκολλο, η δυνατότητα σύνδεσης και η υποστήριξη της γραφικής απεικόνισης και παραμετροποίησης του δικτύου με το dlux. Η εγκατάσταση γίνεται ως εξής: opendaylight-user@root> feature:install <feature> Τα features που απαιτείται να εγκαταστιθούν είναι τα εξής: odl-dlux-all odl-dlux-core odl-dlux-node odl-dlux-yangui odl-dlux-yangvisualizer odl-restconf odl-restconf-noauth odl-aaa-api odl-aaa-authn odl-config-persister odl-config-startup odl-config-netty odl-config-api odl-configcore odl-config-manager odl-openflowplugin-southbound odl-openflowplugin-flow-services odl- openflowplugin-nsf-services odl-openflowplugin-nsf-model odl-openflowpluginflow-services-rest odl-openflowplugin-flow-services-ui odl-openflowplugin-appconfig-pusher odl-openflowplugin-app-lldp-speaker odl-l2switch-switch odl-l2switch-switch-rest odl-l2switch-switch-ui odl-l2switchhosttracker odl-l2switch-addresstracker odl-l2switch-arphandler odl-l2switchloopremover odl-l2switch-packethandler odl-mdsal-common odl-mdsal-broker-local odl-mdsal-xsql odl-mdsal-clusteringcommons odl-mdsal-distributed-datastore odl-mdsal-remoterpc-connector odlmdsal-broker odl-mdsal-clustering odl-mdsal-apidocs odl-mdsal-binding-runtime odl-mdsal-binding-base odl-mdsal-models ssh war http config 45

6.2 Τοπολογία 6.2.1 Τοπολογία των Data Centers Η τοπολογία που χρησιμοποιείται για τα Data Centers είναι της μορφής FatTree κατά την οποία τα τερματικά -ή στην περίπτωση μας- οι εξυπηρετητές βρίσκονται στην κατώτερη στοιβάδα του δέντρου. Το Data Center αποτελείται από: Servers (Εξυπηρετητές) : Τοποθετημένοι σε Racks και συνδεόμενοι στο διαδίκτυο μέσω μεταγωγέων Access/Edge Switches : Το επίπεδο των μεταγωγέων που συνδέεται άμεσα με τους εξυπηρετητές Distribution/Aggregation Switches : Το επίπεδο των μεταγωγέων που συνδέει τους Access μεταγωγείς και τους παρέχει συνδεσιμότητα στο διαδίκτυο Core Switches : Το ανώτερο επίπεδο μεταγωγέων που συνδέεται μόνο με Distribution μεταγωγείς και παρέχει συνδεσιμότητα εντός του Data Center αλλά και εκτός αυτού, σε άλλες γεωγραφικές περιοχές για την πρόσβαση του Data Center στο διαδίκτυο [19] Η μορφή αυτή τριών επιπέδων προτιμάται διότι προσδίδει κλιμακωσιμότητα και εξισορρόπηση της κίνησης στο δίκτυο. Παρακάτω παρουσιάζεται η μορφή που έχουν οι συσκευές σε ένα Data Center Εικόνα 8: Επισκόπηση Αρχιτεκτονικής Fattree σε Data Center 46

6.2.2 Τοπολογία Εφαρμογής Η τοπολογία που επιλέχθηκε να χρησιμοποιηθεί για την εφαρμογή είναι της μορφής FatTree, προσομοιάζοντας έτσι τη μορφή που έχουν οι τοπολογίες στα Data Centers, αφού αποτελούν τα σημεία στα οποία καταναλώνονται τα μεγαλύτερα ποσοστά ενέργειας του διαδικτύου και σε αυτά θα είχε περισσότερη απήχηση η εφαρμογή αυτού του είδους των βελτιστοποιήσεων. Συγκεκριμένα, η τοπολογία είναι της μορφής: Εικόνα 9: Τοπολογία δικτύου εφαρμογής (OpenDaylight DLUX) 47

Η εικόνα ελήφθη μέσω browser από την εφαρμογή DLUX του ODL θέτοντας τα στοιχεία του διαχειριστή στο url: http://<odl-ip>:8181/index.html#/topology Στην παραπάνω τοπολογία υπάρχουν συνολικά 26 switches και 256 τερματικά. Συγκεκριμένα έχουν τοποθετηθεί: 2 core switches, 8 distribution switches, 16 access switches με το κάθε access switch να συνδέεται άμεσα με 16 τερματικά. Να επισημανθεί πως η παραπάνω είναι μια τοπολογία που τυχαίως επιλέχθηκε, και δεν εξαρτάται η λειτουργία της εφαρμογής από αυτή καθώς ό,τι πληροφορία απαιτεί, την λαμβάνει από τον ελεγκτή κάθε φορά που εκκινείται νέο δίκτυο. 48

6.3 Αρχιτεκτονική Εφαρμογής Για την εφαρμογή αξιοποιείται η REST αρχιτεκτονική του ODL και γίνεται χρήση του REST api στο http://<οdl-ip>:8181/restconf/. Στον παρακάτω πίνακα φαίνονται τα μέρη του REST api που χρειάστηκαν καθώς και οι αντίστοιχες μέθοδοι που χρησιμοποιήθηκαν και τα στοιχεία που εξήχθησαν από τον ελεγκτή ή τα στοιχεία που του στάλθηκαν : Μέθοδος URL Στοιχεία που εξήχθησαν ή στάλθηκαν Σχόλια GET http://<odlip>:8181/restconf/operational/networktopology:network-topology/ Λήψη: i) link-id ii) source-node iii) source-tp iv) dest-tp Τα id για το συγκεκριμένο link από τα οποία αργότερα θα εξαχθούν κατάλληλες πληροφορίες όπως : switch-id, MAC διευθύνσεις, portid GET http://<odlip>:8181/restconf/operational/opendaylightinventory:nodes/openflow:<switchid>/nodeconnector/openflow:<switchid>:<port-id>/ Λήψη: flownodeinventory:name Το όνομα του συγκεκριμένου interface GET http://<odlip>:8181/restconf/operational/opendaylightinventory:nodes/openflow:<switchid>/nodeconnector/openflow:<switchid>:local Λήψη: flownodeinventory:name Το όνομα του συγκεκριμένου switch GET http://<odlip>:8181/restconf/operational/opendaylightinventory:nodes/openflow:<switchid>/table/ 0 Λήψη: i) flow-id ii) hash Στοιχεία που θα χρειαστούν για την αναγνώριση της κάθε ροής GET http://<odlip>:8181/restconf/operational/opendaylightinventory:nodes/openflow:<switchid>/table/ 0/flow/<flow-ID> Λήψη: byte-count Ο μετρητής για τα bytes που μεταφέρθηκαν με τη συγκεκριμένη ροή PUT http://<odlαποστολή: Δημιουργία ροής IP>:8181/restconf/operational/opendaylightΤο xml με τα της επιθυμίας μας inventory:nodes/openflow:<switchid>/table/ στοιχεία της ροής 0/flow/<flow-ID> όπως θέλουμε να 49

την παραμετροποιήσ ουμε DELETE http://<odlip>:8181/restconf/operational/opendaylightinventory:nodes/openflow:<switchid>/table/ 0/flow/<flow-ID> Αποστολή: Το xml αρχείο που συνιστά τη συγκεκριμένη ροή Διαγραφή της συγκεκριμένης ροής DELETE http://<odlip>:8181/restconf/config/opendaylightinventory:nodes/ Αποστολή: Όλο το περιεχόμενο του config state Διαγραφή όλου του config state Πίνακας με τις μεθόδους που χρησιμοποιήθηκαν στο REST api Εν γένει, τροποποίηση γίνεται μόνο στο config state, το οποίο ενημερώνει αυτόματα το operational state του ελεγκτή. Από το operational state, ο διαχειριστής λαμβάνει τις πληροφορίες που επιθυμεί. Ως γλώσσα προγραμματισμού επιλέχθηκε η python διότι μπορεί εύκολα κανείς μέσω αυτής να εκτελέσει bash εντολές που μας ήταν απαραίτητες. Συνδυάστηκε η python με bash shell scripting προκειμένου να εκμεταλλευτούμε το REST api του ODL μέσω της εντολής curl. Η εφαρμογή δεν απαιτεί την ύπαρξη browser, ούτε καν την ύπαρξη γραφικού περιβάλλοντος στο μηχάνημα που εκτελείται. Μπορεί εύκολα ο διαχειριστής απομακρυσμένα, με ένα εικονικό μηχάνημα (VM) και ένα terminal να εκτελέσει την εφαρμογή ελέγχοντας το δίκτυο του. Απαραίτητη είναι η επαλήθευση ταυτότητας και αδειοδότηση του χρήστη με τα στοιχεία του διαχειριστή (username, password) καθώς και η εγκατάσταση των βιβλιοθηκών που βρίσκονται στις επικεφαλίδες των python αρχείων και του cplex. Για την προσθήκη καινούριων ροών που θα περιγραφτεί παρακάτω, εκμεταλλευτήκαμε τις δυνατότητες του Openflow πρωτοκόλλου, το οποίο και είναι υπεύθυνο για κάθε επικοινωνία του ελεγκτή με τα switches. Ουσιαστικά το REST api είναι υπεύθυνο για την εξωτερική επικοινωνία που έχει ο διαχειριστής-εφαρμογή με τον 50

ελεγκτή και το Openflow είναι υπεύθυνο για την επικοινωνία εντός του δικτύου (μεταξύ ελεγκτή - switches). Συνοψίζοντας, παρουσιάζεται η αρχιτεκτονική της εφαρμογής στην παρακάτω εικόνα. Εικόνα 10: Αρχιτεκτονική Συστήματος Η εικόνα αφορά σε γενική αρχιτεκτονική του συστήματος, της συνδεσμολογίας και της επικοινωνίας μεταξύ των μηχανημάτων. 51

6.3.1 Διάγραμμα Ροής Σύνοψη εφαρμογής Εικόνα 11: Διάγραμμα ροής της εφαρμογής 52