Sdnni tashkil etish asoslari: openflow, kontroller, nfv va xavfsizlik - bet 2

|
Sdnni tashkil etish asoslari: openflow, kontroller, nfv va xavfsizlik
|
bet | 2/10 | Sana | 02.06.2024 | Hajmi | 0,69 Mb. | | #259330 |
Bog'liq a8RS2ifQROTxghJOCEm7KyHWaS53ZSSfS7aiX29PFaol tarmoqlar. 1990-yillarning boshlarida internetning yuksalishi kuzatildi, fayl uzatish va elektron pochtadan tashqari koʻplab yangi ilovalar paydo boʻldi. Ilovalarning bunday xilma-xilligi yangi tarmoq xizmatlarini va ular uchun yangi aloqa protokollarini ishlab chiqishga turtki bo‘ldi. Ushbu yangi protokollar IETF (Internet Engineering Task Force) deb nomlangan tashkilot tomonidan standartlashtirilgan.
Ko‘plab tadqiqotchilar va ishlab chiquvchilar dastlab internetda nazarda tutilgan yondashuvlardan farqli ravishda muqobil yondashuvni qo‘llashni boshladilar. Gap shundaki, internetning prototipi ARPAnet asosiy g‘oyasi tarmoqning katta qismi ishlamay qolganda (masalan, nosozliklar yuzaga kelganda) tarmoqning ish faoliyatini saqlab qolish imkoniyati edi. Shuning uchun, har bir tarmoq elementi keyingi paketni qaysi yo‘nalishda yuborishni mustaqil ravishda hal qilishi kerak edi. Bu g‘oya harbiy qo‘llanmalar uchun to‘g‘ri edi, ammo fuqarolik maqsadlarida va hatto turli xil xizmatlarda ham, u innovatsiyalarga to‘sqinlik qiladigan va tarmoqni qurish va saqlash xarajatlarini oshiradigan katta zaiflikga aylandi.
An’anaviy kompyuter tarmoqlari hech qanday ma’noda «dasturlanmaydigan» bo‘lgan. «Faol tarmoqlar» tushunchasi uchun amaliy dasturlash interfeysi API (Application Programming Interface) tushunchasi kiritildi. Ushbu interfeys yuqori darajadagi boshqarish uchun alohida tarmoq tugunlarida tarmoq elementlari resurslarini (protsessorlar, xotira, paket navbatlari) «ko‘rsatish» uchun mo‘ljallangan, bu resurslarni ma’lum amaliy dasturlarni bajarish uchun API interfeysi orqali boshqaradi. Biroq, bu yondashuv Internet hamjamiyatida katta ishtiyoq tug‘dirmadi, ular asosiy tarmoqning «oddiyligi»ni himoya qildilar va bu Internet muvaffaqiyatining asosi ekanligini ta’kidladilar. «Faol tarmoq» yondashuvi GENI (Global Environment for Network Innovations), shuningdek, AQShda NSF FIND (Future Internet Design) va Yevropada Yevropa Ittifoqi FIRE (Future Internet Research and Experimentation Initiative) kabi tashkilotlarda ishlab chiqila boshlandi.
Ushbu innovatsion tashkilotlar tarmoqni dasturlashning ikkita asosiy modelini ishlab chiqdi:
«Kapsula» modeli, bu yerda boshqaruv kodlari ma’lumotlar paketlariga «mustahkam ulangan» (in-band);
«Dasturlashtiriladigan kommutatorlar va marshrutizatorlar» modeli, bu yerda boshqaruv buyruqlarini uzatuvchi alohida paketlar ishlatilgan (out-of-band).
Biroq, bu yondashuv ko‘pincha «sotuvchiga bog‘liq» edi (ko‘pgina ishlab chiqaruvchilar tarmoq dasturlash tillarining o‘z versiyalarini ishlab chiqdilar), bu «middleboxes» deya nomlanadigan – tarmoqlararo ekran, proksi-serverlar va boshqa tarmoq qurilmalarini alohida boshqaruvni talab qildi. O‘sha paytda allaqachon standart serverlarda ishlaydigan virtual mashinalarda turli tarmoq elementlarining funksiyalarini amalga oshiradigan NFV (Network Functions Virtualization) tarmoq funksiyalarini virtualizatsiya qilish texnologiyasining asoslari yaratilgan.
Biroq, faol tarmoq texnologiyasi bir muhim kamchilikka ega edi. Yakuniy foydalanuvchilar ilovalarni ishlab chiqishlari va ularni dastur serverlarida ishga tushirishlari va ilovalar yaxshi ishlashi uchun tarmoqlarni mos ravishda sozlashlari taxmin qilingan. Cheksiz resurslarga va unumdorlikka ega bo‘lgan tarmoq uchun bu ehtimol ishlaydi, ammo cheklangan resurslar sharoitida API orqali dasturlashning umumiy tarqalishi tarmoq resurslarini ilg‘or foydalanuvchilar tor doirasi tomonidan tortib olinishiga olib keladi.
Bundan tashqari, «faol tarmoq» yetarli darajada unumdor emasligi va xavfsizlikni talab darajasida ta’minlamasligi ma’lum bo‘ldi. Shuning uchun alohida Secure Active Network Environment Architecture loyihasi yaratildi. Natijada, texnologiya sezilarli darajada tarqalmagan. Laboratoriyalarda hamma narsa yaxshi ishladi, ammo dolzarb muammolarni hal qilib bo‘lmadi. Shu sababli, keyingi tadqiqotlar faqat boshqaruv va ma’lumotlar tekisliklarini ajratishga qaratilgan.
Boshqaruv va ma’lumotlar tekisliklarini ajratish. 2000-yillarning boshlarida tarmoq trafigining ortib borayotgan hajmi va tarmoq barqarorligi va unumdorligiga boʻlgan talablar «Traffic Engineering» TE (Traffic Engineering) deb nomlangan media oqimini boshqarish kabi tarmoq boshqaruviga yanada yaxshi yondashuvlarni talab qildi. Biroq, mavjud tarmoq protokollari buning uchun mos emas edi. Buning sababi yana an’anaviy marshrutizatorlar va kommutatorlarda boshqaruv tekisliklarini ajratish va ma’lumotlar paketlarini uzatishga ega emasligi edi. Shu sababli, bu tekisliklarni ajratish uchun birinchi urinishlar qilindi. Bu ikkita asosiy innovatsiyaga olib keldi:
IETF yoki Linux uchun Netlink tomonidan standartlashtirilgan ForCES (Forwarding and Control Element Separation) kabi boshqaruv va maʼlumotlar tekisliklari oʻrtasida ochiq interfeyslarni ishlab chiqish;
RCP (Routing Control Platform) marshrutlashni boshqarish protokolini, shuningdek, «dasturlashtiriladigan marshrutizatorlar» (Soft-Router) va PCE (Path Computation Element) arxitekturasini ishlab chiqish.
Ushbu innovatsiyalar internet-provayder (ISP) tarmog‘ida marshrutlash jarayonini boshqarish zarurati bilan bog‘liq. Ular endi oxirgi foydalanuvchilarga emas, balki tarmoq administratorlariga qaratilgan edi. Ular boshqaruv tekisligida dasturlash imkoniyatini, butun tarmoq topologiyasini vizualizatsiya qilish va boshqarishni, alohida tarmoq qurilmalari konfiguratsiyasini emas, ma’lumotlar tekisligida dasturlash imkoniyatini talab qildilar.
Tarmoqni boshqarish funksiyasini tarmoq apparatidan uzoqroqqa va alohida serverlarga ko‘chirish mantiqiy edi, chunki tarmoq boshqaruvi uning alohida qurilmalariga emas, balki butun tarmoqqa ta’sir qiladi. Server texnologiyalaridagi yutuqlar barcha marshrutlarning holatini va butun yirik internet-provayder tarmog‘ida barcha trafikni yo‘naltirish qarorlarini yagona standart serverda hisoblash imkonini berdi. Ushbu faoliyatning barchasini band qilish boshqa standart serverda - asosiy server bilan parallel ravishda ishlaydigan zaxira serverda amalga oshirilishi mumkin. Shunday qilib, nazoratning ishonchliligi ta’minlandi.
Ushbu innovatsion arxitekturalar taklif qilingandan so‘ng, hamma IT mutaxassislari ham ularga ishtiyoq bilan qaramadilar. Ko‘pgina operatorlar tekisliklarni bo‘lish birinchi navbatda yomon fikr deb hisoblashdi, chunki markaziy boshqaruvchi ishlamay qolsa, tarmoqqa nima bo‘lishini hech kim aniq aytolmaydi. Tarmoq elementlari o‘zaro marshrutlar haqida ma’lumot almashish modeli, ularga ko‘proq yoqdi, bu, albatta mutaxassislarga, sodda va tushunarli ko‘rinar edi.
Bundan tashqari, asosiy ishlab chiqaruvchilarga ForCES kabi API g‘oyasi unchalik yoqmadi, chunki ochiq APIlar ko‘plab kichik raqobatchilarga bozorga kirishga imkon berar edi.
Tadqiqotchilar tekisliklarni ajratish yo‘nalishi bo‘yicha o‘z ishlarini davom ettirdilar va obyektga yo‘naltirilgan dasturlashga o‘xshash «clean-slate» deb ataladigan arxitekturalarni ishlab chiqishga kirishdilar. 4D loyihasida ko‘proq mavhumlik uchun to‘rtta tekislik taklif qilindi:
ma’lumotlar tekisligi (data plane), sozlanishi qoidalar asosida paketlarni qayta ishlash uchun;
qidiruv tekisligi (discovery plane), topologiya haqida ma’lumot to‘plash va trafikni o‘lchash uchun;
tarqatish tekisligi (dissemination plane), tarmoq tugunlarida paketlarni qayta ishlash qoidalarini o‘rnatish;
qaror tekisligi (decision plane), tarmoq sathi maqsadlarini paketlarni qayta ishlash holatlariga aylantiruvchi mantiqiy markazlashtirilgan kontrollerlardan tashkil topgan.
|
| |