В წინა ნომერი მე აღვწერე ქსელის ავტომატიზაციის ჩარჩო. ზოგიერთის აზრით, პრობლემისადმი ამ პირველმა მიდგომამ უკვე მოაგვარა გარკვეული კითხვები. და ეს ძალიან მახარებს, რადგან ჩვენი მიზანი ციკლში არ არის Ansible-ის დაფარვა პითონის სკრიპტებით, არამედ სისტემის აშენება.

იგივე ჩარჩო ადგენს თანმიმდევრობას, რომლითაც შევეხებით კითხვას.
და ქსელის ვირტუალიზაცია, რომელსაც ეს საკითხი ეძღვნება, განსაკუთრებით არ ჯდება ADSM თემაში, სადაც ვაანალიზებთ ავტომატიზაციას.

მაგრამ მოდით შევხედოთ მას სხვა კუთხით.

ბევრი სერვისი დიდი ხანია იყენებს ერთსა და იმავე ქსელს. ტელეკომის ოპერატორის შემთხვევაში, ეს არის მაგალითად 2G, 3G, LTE, ფართოზოლოვანი და B2B. DC-ის შემთხვევაში: კავშირი სხვადასხვა კლიენტებისთვის, ინტერნეტი, ბლოკის საცავი, ობიექტების შენახვა.

და ყველა სერვისი მოითხოვს ერთმანეთისგან იზოლირებას. ასე გაჩნდა გადაფარვის ქსელები.

და ყველა სერვისს არ სურს დაელოდოს ადამიანს, რომ ხელით დააკონფიგურიროს ისინი. ასე გამოჩნდნენ ორკესტრატორები და SDN.

ქსელის სისტემატური ავტომატიზაციის პირველი მიდგომა, უფრო სწორად, მისი ნაწილი, დიდი ხანია მიღებული და დანერგილია ბევრგან: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

ეს არის ის, რასაც ჩვენ დღეს გავუმკლავდებით.

ინფორმაციის

• მიზეზები
• ტერმინოლოგია
• Underlay - ფიზიკური ქსელი
• გადაფარვა - ვირტუალური ქსელი
  • გადაფარვა ToR-ით
  • გადაფარვა მასპინძლისგან
  • მაგალითად ვოლფრამის ქსოვილის გამოყენება
    • კომუნიკაცია ერთ ფიზიკურ მანქანაში
    • კომუნიკაცია VM-ებს შორის, რომლებიც მდებარეობს სხვადასხვა ფიზიკურ მანქანებზე
    • გასვლა გარე სამყაროში

• კითხვა-პასუხი
• დასკვნა
• სასარგებლო ბმულები

მიზეზები

და რადგან ჩვენ ვსაუბრობთ ამაზე, აღსანიშნავია ქსელის ვირტუალიზაციის წინაპირობები. ფაქტობრივად, ეს პროცესი გუშინ არ დაწყებულა.

ალბათ არაერთხელ გსმენიათ, რომ ქსელი ყოველთვის იყო ნებისმიერი სისტემის ყველაზე ინერტული ნაწილი. და ეს მართალია ყველა გაგებით. ქსელი არის საფუძველი, რომელზედაც ყველაფერი ეყრდნობა და მასზე ცვლილებების შეტანა საკმაოდ რთულია - სერვისები ამას არ იტანენ, როდესაც ქსელი გათიშულია. ხშირად, ერთი კვანძის გაუქმებამ შეიძლება წაშალოს აპლიკაციების დიდი ნაწილი და გავლენა მოახდინოს ბევრ მომხმარებელზე. ნაწილობრივ ეს არის მიზეზი, რის გამოც ქსელის გუნდმა შეიძლება წინააღმდეგობა გაუწიოს ნებისმიერ ცვლილებას - რადგან ახლა ის რატომღაც მუშაობს (შეიძლება არც კი ვიცით როგორ), მაგრამ აქ თქვენ უნდა დააკონფიგურიროთ რაღაც ახალი და უცნობია როგორ იმოქმედებს ეს ქსელზე.

იმისთვის, რომ არ დაელოდონ ქსელების მიერ VLAN-ების ჩასმას და არ დაარეგისტრირონ რაიმე სერვისი თითოეულ ქსელის კვანძზე, ხალხს გაუჩნდა იდეა, რომ გამოეყენებინათ გადაფარვები - გადაფარვის ქსელები - რომელთაგან მრავალფეროვანია: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE და ა.შ.

მათი მიმზიდველობა მდგომარეობს ორ მარტივ რამეში:

• კონფიგურირებულია მხოლოდ ბოლო კვანძები - სატრანზიტო კვანძებს არ სჭირდებათ შეხება. ეს მნიშვნელოვნად აჩქარებს პროცესს და ზოგჯერ საშუალებას გაძლევთ მთლიანად გამორიცხოთ ქსელის ინფრასტრუქტურის განყოფილება ახალი სერვისების დანერგვის პროცესისგან.
• დატვირთვა იმალება სათაურებში ღრმად - სატრანზიტო კვანძებს არ სჭირდებათ ამის შესახებ არაფერი იცოდნენ, ჰოსტებზე მიმართვის შესახებ ან გადაფარვის ქსელის მარშრუტების შესახებ. ეს ნიშნავს, რომ თქვენ გჭირდებათ ნაკლები ინფორმაციის შენახვა ცხრილებში, რაც ნიშნავს უფრო მარტივი/იაფი მოწყობილობის გამოყენებას.

ამ არც თუ ისე სრულფასოვან საკითხში, მე არ ვაპირებ ყველა შესაძლო ტექნოლოგიის ანალიზს, არამედ აღვწერ DC-ებში გადაფარვის ქსელების მუშაობის ჩარჩოს.

მთელი სერია აღწერს მონაცემთა ცენტრს, რომელიც შედგება იდენტური თაროების რიგებისგან, რომლებშიც დამონტაჟებულია იგივე სერვერის მოწყობილობა.

ეს მოწყობილობა მართავს ვირტუალურ მანქანებს/კონტეინერებს/სერვერის გარეშე, რომლებიც ახორციელებენ სერვისებს.

ტერმინოლოგია

მარყუჟში სერვერი დავასახელებ პროგრამას, რომელიც ახორციელებს კლიენტ-სერვერ კომუნიკაციის სერვერის მხარეს.

თაროებში არსებულ ფიზიკურ მანქანებს სერვერები ეწოდება არარის ჩვენ.

ფიზიკური მანქანა — თაროში დაყენებული x86 კომპიუტერი. ყველაზე ხშირად გამოყენებული ტერმინი მასპინძელი. ასე დავარქმევთ მას"მანქანის"ან მასპინძელი.

ჰიპერვიზორი - ფიზიკურ აპარატზე გაშვებული აპლიკაცია, რომელიც ასახავს იმ ფიზიკურ რესურსებს, რომლებზეც მუშაობს ვირტუალური მანქანები. ზოგჯერ ლიტერატურაში და ინტერნეტში სიტყვა „ჰიპერვიზორი“ გამოიყენება „მასპინძლის“ სინონიმად.

Ვირტუალური ხელსაწყო - ოპერაციული სისტემა, რომელიც მუშაობს ფიზიკურ აპარატზე ჰიპერვიზორის თავზე. ჩვენთვის ამ ციკლში არ აქვს მნიშვნელობა რეალურად არის ეს ვირტუალური მანქანა თუ უბრალოდ კონტეინერი. მოდით დავარქვათ "ვ.მ.«

მოიჯარე არის ფართო კონცეფცია, რომელსაც ამ სტატიაში განვსაზღვრავ, როგორც ცალკე სერვისს ან ცალკე კლიენტს.

მრავალბინიანი ან multitenancy - ერთი და იგივე აპლიკაციის გამოყენება სხვადასხვა კლიენტის/მომსახურების მიერ. ამავდროულად, კლიენტების ერთმანეთისგან იზოლირება მიიღწევა აპლიკაციის არქიტექტურის წყალობით და არა ცალკე გაშვებული ინსტანციებით.

ToR - თაროს გადამრთველის ზედა ნაწილი - ჩამრთველი დამონტაჟებული თაროში, რომელსაც ყველა ფიზიკური მანქანა უკავშირდება.

ToR ტოპოლოგიის გარდა, სხვადასხვა პროვაიდერი პრაქტიკაში ახორციელებს End of Row (EoR) ან Middle of Row (თუმცა ეს უკანასკნელი დამამცირებელი იშვიათობაა და მე არ მინახავს MoR აბრევიატურა).

საფენის ქსელი ან ძირითადი ქსელი ან ქვედანაყოფი არის ფიზიკური ქსელის ინფრასტრუქტურა: კონცენტრატორები, მარშრუტიზატორები, კაბელები.

გადაფარვის ქსელი ან გადაფარვის ქსელი ან გადაფარვა - ფიზიკურზე გაშვებული გვირაბების ვირტუალური ქსელი.

L3 ქსოვილი ან IP ქსოვილი - კაცობრიობის საოცარი გამოგონება, რომელიც საშუალებას გაძლევთ თავიდან აიცილოთ STP-ის გამეორება და ინტერვიუებისთვის TRILL-ის სწავლა. კონცეფცია, რომელშიც მთელი ქსელი წვდომის დონემდე არის ექსკლუზიურად L3, VLAN-ების და, შესაბამისად, უზარმაზარი გაფართოებული სამაუწყებლო დომენების გარეშე. ჩვენ გავარკვევთ, საიდან მოდის სიტყვა "ქარხანა" შემდეგ ნაწილში.

SDN - პროგრამული უზრუნველყოფის განსაზღვრული ქსელი. შესავალი ძლივს სჭირდება. ქსელის მენეჯმენტის მიდგომა, სადაც ქსელში ცვლილებები ხდება არა პიროვნების, არამედ პროგრამის მიერ. ჩვეულებრივ ნიშნავს საკონტროლო სიბრტყის გადატანას ქსელის ბოლო მოწყობილობების მიღმა კონტროლერზე.

NFV — ქსელის ფუნქციის ვირტუალიზაცია — ქსელური მოწყობილობების ვირტუალიზაცია, რაც ვარაუდობს, რომ ზოგიერთი ქსელის ფუნქცია შეიძლება განხორციელდეს ვირტუალური მანქანების ან კონტეინერების სახით, რათა დააჩქაროს ახალი სერვისების განხორციელება, მოაწყოს სერვისის ჯაჭვის ორგანიზება და უფრო მარტივი ჰორიზონტალური მასშტაბირება.

VNF - ვირტუალური ქსელის ფუნქცია. კონკრეტული ვირტუალური მოწყობილობა: როუტერი, გადამრთველი, firewall, NAT, IPS/IDS და ა.შ.

ახლა განზრახ ვამარტივებ აღწერას კონკრეტულ განხორციელებამდე, რათა მკითხველი ძალიან არ დააბნიოს. უფრო გააზრებული კითხვისთვის მე მივმართავ მას განყოფილებაში ლიტერატურა. გარდა ამისა, რომის ხეობა, რომელიც აკრიტიკებს ამ სტატიას უზუსტობების გამო, გვპირდება ცალკე საკითხს დაწერს სერვერებისა და ქსელების ვირტუალიზაციის ტექნოლოგიების შესახებ, უფრო ღრმა და დეტალებისადმი ყურადღებიანი.

დღეს ქსელების უმეტესობა აშკარად შეიძლება დაიყოს ორ ნაწილად:

ქვედანაყოფი — ფიზიკური ქსელი სტაბილური კონფიგურაციით.
Overlay - აბსტრაქცია Underlay-ზე მოიჯარეების იზოლირებისთვის.

ეს ეხება როგორც DC-ს (რომელსაც გავაანალიზებთ ამ სტატიაში) ასევე ISP-სთვის (რომელსაც ჩვენ არ გავაანალიზებთ, რადგან უკვე სდსმ). საწარმოთა ქსელებთან, რა თქმა უნდა, სიტუაცია გარკვეულწილად განსხვავებულია.

სურათი ფოკუსირებული ქსელში:

ქვედანაყოფი

Underlay არის ფიზიკური ქსელი: ტექნიკის კონცენტრატორები და კაბელები. მიწისქვეშა მოწყობილობებმა იციან როგორ მიაღწიონ ფიზიკურ მანქანებს.

ის ეყრდნობა სტანდარტულ პროტოკოლებსა და ტექნოლოგიებს. განსაკუთრებით იმიტომ, რომ ტექნიკის მოწყობილობები დღემდე მუშაობს საკუთრების პროგრამულ უზრუნველყოფაზე, რომელიც არ იძლევა ჩიპის დაპროგრამებას ან საკუთარი პროტოკოლების დანერგვას; შესაბამისად, საჭიროა სხვა მომწოდებლებთან თავსებადობა და სტანდარტიზაცია.

მაგრამ Google-ის მსგავს ადამიანს შეუძლია შეიმუშაოს საკუთარი კონცენტრატორები და მიატოვოს ზოგადად მიღებული პროტოკოლები. მაგრამ LAN_DC არ არის Google.

Underlay იცვლება შედარებით იშვიათად, რადგან მისი ამოცანაა ძირითადი IP კავშირი ფიზიკურ მანქანებს შორის. Underlay-მ არაფერი იცის სერვისების, კლიენტების ან მოიჯარეების შესახებ, რომლებიც მასზე მუშაობენ - მას მხოლოდ ერთი მანქანიდან მეორეზე პაკეტის მიწოდება სჭირდება.
ქვედაბოლო შეიძლება იყოს ასეთი:

• IPv4+OSPF
• IPv6+ISIS+BGP+L3VPN
• L2+TRILL
• L2 + STP

Underlay ქსელი კონფიგურირებულია კლასიკური გზით: CLI/GUI/NETCONF.

ხელით, სკრიპტები, საკუთრების კომუნალური საშუალებები.

სერიის შემდეგი სტატია უფრო დეტალურად დაეთმობა ქვედა ფენას.

Overlay

Overlay არის Underlay-ის თავზე გადაჭიმული გვირაბების ვირტუალური ქსელი, რომელიც საშუალებას აძლევს ერთი კლიენტის ვირტუალურ საშუალებებს დაუკავშირდნენ ერთმანეთს, ხოლო უზრუნველყოფენ იზოლირებას სხვა კლიენტებისგან.

კლიენტის მონაცემები ჩასმულია გვირაბის ზოგიერთ სათაურში საჯარო ქსელში გადასაცემად.

ასე რომ, ერთი კლიენტის (ერთი სერვისის) VM-ებს შეუძლიათ ერთმანეთთან კომუნიკაცია Overlay-ის საშუალებით, არც კი იცოდნენ, თუ რა გზას გადის პაკეტი რეალურად.

გადაფარვა შეიძლება იყოს, მაგალითად, როგორც ზემოთ აღვნიშნე:

• GRE გვირაბი
• VXLAN
• EVPN
• L3VPN
• ჯენივე

გადაფარვის ქსელი, როგორც წესი, კონფიგურირებული და შენარჩუნებულია ცენტრალური კონტროლერის მეშვეობით. მისგან კონფიგურაცია, საკონტროლო თვითმფრინავი და მონაცემთა სიბრტყე მიეწოდება მოწყობილობებს, რომლებიც მარშრუტებენ და ახდენენ კლიენტის ტრაფიკს. Ცოტა ქვემოთ მოდით შევხედოთ ამას მაგალითებით.

დიახ, ეს არის SDN მისი სუფთა სახით.

არსებობს ორი ფუნდამენტურად განსხვავებული მიდგომა Overlay ქსელის ორგანიზებისთვის:

1. გადაფარვა ToR-ით
2. გადაფარვა მასპინძლისგან

გადაფარვა ToR-ით

გადაფარვა შეიძლება დაიწყოს თაროში მდგარი წვდომის გადამრთველიდან (ToR), როგორც ეს ხდება, მაგალითად, VXLAN ქსოვილის შემთხვევაში.

ეს არის დროში გამოცდილი მექანიზმი ISP ქსელებზე და ქსელური აღჭურვილობის ყველა გამყიდველი მხარს უჭერს მას.

თუმცა, ამ შემთხვევაში, ToR გადამრთველს უნდა შეეძლოს სხვადასხვა სერვისების გამოყოფა, შესაბამისად, და ქსელის ადმინისტრატორმა, გარკვეულწილად, უნდა ითანამშრომლოს ვირტუალური მანქანის ადმინისტრატორებთან და შეიტანოს ცვლილებები (თუმცა ავტომატურად) მოწყობილობების კონფიგურაციაში. .

აქ მკითხველს მივმართავ სტატიას ამის შესახებ VxLAN Habré-ზე ჩვენი ძველი მეგობარი @bormoglotx.
ამაში პრეზენტაციები ENOG-თან EVPN VXLAN ქსოვილით DC ქსელის აგების მიდგომები დეტალურად არის აღწერილი.

და რეალობაში უფრო სრულყოფილი ჩაძირვისთვის შეგიძლიათ წაიკითხოთ ცისკას წიგნი თანამედროვე, ღია და მასშტაბირებადი ქსოვილი: VXLAN EVPN.

მე აღვნიშნავ, რომ VXLAN არის მხოლოდ ინკაფსულაციის მეთოდი და გვირაბების შეწყვეტა შეიძლება მოხდეს არა ToR-ზე, არამედ ჰოსტზე, როგორც ეს ხდება, მაგალითად, OpenStack-ის შემთხვევაში.

თუმცა, VXLAN ქსოვილი, სადაც გადაფარვა იწყება ToR-ზე, არის ერთ-ერთი დამკვიდრებული გადაფარვის ქსელის დიზაინი.

გადაფარვა მასპინძლისგან

კიდევ ერთი მიდგომაა გვირაბების დაწყება და დასრულება ბოლო მასპინძლებზე.
ამ შემთხვევაში, ქსელი (Underlay) რჩება რაც შეიძლება მარტივი და სტატიკური.
და მასპინძელი თავად აკეთებს ყველა საჭირო ინკაფსულაციას.

რა თქმა უნდა, ამას დასჭირდება სპეციალური აპლიკაციის გაშვება მასპინძლებზე, მაგრამ ღირს.

უპირველეს ყოვლისა, კლიენტის გაშვება Linux აპარატზე უფრო ადვილია ან, ვთქვათ, შესაძლებელია, ხოლო გადამრთველზე, სავარაუდოდ, მოგიწევთ მიმართოთ საკუთრების SDN გადაწყვეტილებებს, რაც კლავს მრავალ გამყიდველის იდეას.

მეორეც, ToR შეცვლა ამ შემთხვევაში შეიძლება დარჩეს რაც შეიძლება მარტივი, როგორც საკონტროლო სიბრტყის, ასევე მონაცემთა სიბრტყის თვალსაზრისით. მართლაც, მაშინ მას არ სჭირდება კომუნიკაცია SDN კონტროლერთან და ასევე არ სჭირდება ყველა დაკავშირებული კლიენტის ქსელების/ARP-ების შენახვა - საკმარისია იცოდეთ ფიზიკური აპარატის IP მისამართი, რაც მნიშვნელოვნად ამარტივებს გადართვას/ მარშრუტიზაციის მაგიდები.

ADSM სერიაში მე ვირჩევ გადაფარვის მიდგომას მასპინძლისგან - შემდეგ მხოლოდ ამაზე ვსაუბრობთ და VXLAN ქარხანაში არ დავბრუნდებით.

ყველაზე ადვილია მაგალითების ნახვა. და როგორც სატესტო საგანი, ჩვენ ავიღებთ OpenSource SDN პლატფორმას OpenContrail, რომელიც ახლა ცნობილია როგორც ვოლფრამის ქსოვილი.

სტატიის ბოლოს მე შემოგთავაზებთ რამდენიმე აზრს OpenFlow-თან და OpenvSwitch-თან ანალოგიის შესახებ.

მაგალითად ვოლფრამის ქსოვილის გამოყენება

თითოეულ ფიზიკურ მანქანას აქვს vროუტერი - ვირტუალური როუტერი, რომელმაც იცის მასთან დაკავშირებული ქსელების შესახებ და რომელ კლიენტებს ეკუთვნის ისინი - ძირითადად PE როუტერი. თითოეული კლიენტისთვის ის ინახავს იზოლირებულ მარშრუტიზაციის ცხრილს (წაიკითხეთ VRF). და vRouter რეალურად აკეთებს Overlay tunneling.

ცოტა მეტი vRouter-ის შესახებ არის სტატიის ბოლოს.

ჰიპერვიზორზე განთავსებული თითოეული VM დაკავშირებულია ამ აპარატის vRouter-თან TAP ინტერფეისი.

Tap - ტერმინალის წვდომის წერტილი - ვირტუალური ინტერფეისი ლინუქსის ბირთვში, რომელიც საშუალებას აძლევს ქსელში ურთიერთქმედებას.

თუ vRouter-ის უკან რამდენიმე ქსელია, მაშინ თითოეული მათგანისთვის იქმნება ვირტუალური ინტერფეისი, რომელსაც ენიჭება IP მისამართი - ეს იქნება ნაგულისხმევი კარიბჭის მისამართი.
ერთი კლიენტის ყველა ქსელი მოთავსებულია ერთში VRF (ერთი მაგიდა), სხვადასხვა - სხვადასხვაში.
მე გამოვთქვამ უარი პასუხისმგებლობაზე, რომ ყველაფერი ასე მარტივი არ არის და ცნობისმოყვარე მკითხველს სტატიის ბოლომდე გავუგზავნი.

რათა vRouters-მა შეძლოს ერთმანეთთან კომუნიკაცია და, შესაბამისად, მათ უკან მდებარე VM-ები, ისინი გაცვლიან მარშრუტიზაციის ინფორმაციას. SDN კონტროლერი.

გარე სამყაროში გასასვლელად, მატრიციდან არის გასასვლელი წერტილი - ვირტუალური ქსელის კარიბჭე VNGW - ვირტუალური ქსელის კარიბჭე (ჩემი ვადა).

ახლა მოდით გადავხედოთ კომუნიკაციების მაგალითებს - და იქნება სიცხადე.

კომუნიკაცია ერთ ფიზიკურ მანქანაში

VM0-ს სურს გაგზავნოს პაკეტი VM2-ში. მოდით, ახლა დავუშვათ, რომ ეს არის ერთი კლიენტი VM.

მონაცემთა თვითმფრინავი

1. VM-0-ს აქვს ნაგულისხმევი მარშრუტი მისი eth0 ინტერფეისისკენ. პაკეტი იგზავნება იქ.
   ეს ინტერფეისი eth0 რეალურად უკავშირდება ვირტუალურ როუტერს vRouter-ს TAP ინტერფეისის tap0-ით.
2. vRouter აანალიზებს რომელ ინტერფეისში მოვიდა პაკეტი, ანუ რომელ კლიენტს (VRF) ეკუთვნის და ამოწმებს მიმღების მისამართს ამ კლიენტის მარშრუტიზაციის ცხრილით.
3. როდესაც აღმოაჩინა, რომ იმავე აპარატზე მიმღები სხვა პორტზეა, vRouter უბრალოდ უგზავნის პაკეტს მას დამატებითი სათაურის გარეშე - ამ შემთხვევაში, vRouter-ს უკვე აქვს ARP ჩანაწერი.

ამ შემთხვევაში, პაკეტი არ შედის ფიზიკურ ქსელში - ის გადადის vRouter-ში.

საკონტროლო თვითმფრინავი

როდესაც ვირტუალური მანქანა იწყება, ჰიპერვიზორი ეუბნება მას:

• მისი საკუთარი IP მისამართი.
• ნაგულისხმევი მარშრუტი არის vRouter-ის IP მისამართის მეშვეობით ამ ქსელში.

ჰიპერვიზორი აცნობებს vRouter-ს სპეციალური API-ის მეშვეობით:

• რა გჭირდებათ ვირტუალური ინტერფეისის შესაქმნელად.
• რა სახის ვირტუალური ქსელი სჭირდება მას (VM) შექმნას?
• რომელ VRF-თან (VN) უნდა დააკავშიროთ იგი.
• სტატიკური ARP ჩანაწერი ამ VM-ისთვის - რომელი ინტერფეისი დგას მისი IP მისამართის უკან და რომელ MAC მისამართთან არის დაკავშირებული.

ისევ და ისევ, ფაქტობრივი ურთიერთქმედების პროცედურა გამარტივებულია კონცეფციის გასაგებად.

ამრიგად, vRouter ხედავს ერთი კლიენტის ყველა VM-ს მოცემულ მანქანაზე, როგორც პირდაპირ დაკავშირებულ ქსელებად და თავად შეუძლია მათ შორის მარშრუტირება.

მაგრამ VM0 და VM1 ეკუთვნის სხვადასხვა კლიენტებს და, შესაბამისად, სხვადასხვა vRouter ცხრილებშია.

შეუძლიათ თუ არა მათ ერთმანეთთან კომუნიკაცია პირდაპირ დამოკიდებულია vRouter-ის პარამეტრებზე და ქსელის დიზაინზე.
მაგალითად, თუ ორივე კლიენტის VM იყენებს საჯარო მისამართებს, ან NAT ხდება თავად vRouter-ზე, მაშინ შეიძლება განხორციელდეს პირდაპირი მარშრუტირება vRouter-ზე.

საპირისპირო სიტუაციაში შესაძლებელია მისამართების სივრცეების გადაკვეთა - თქვენ უნდა გაიაროთ NAT სერვერი საჯარო მისამართის მისაღებად - ეს გარე ქსელებზე წვდომის მსგავსია, რომლებიც ქვემოთ განიხილება.

კომუნიკაცია VM-ებს შორის, რომლებიც მდებარეობს სხვადასხვა ფიზიკურ მანქანებზე

მონაცემთა თვითმფრინავი

1. დასაწყისი ზუსტად იგივეა: VM-0 აგზავნის პაკეტს დანიშნულების VM-7 (172.17.3.2) ნაგულისხმევად.
2. vRouter იღებს მას და ამჯერად ხედავს, რომ დანიშნულების ადგილი სხვა აპარატზეა და ხელმისაწვდომია Tunnel0-ით.
3. პირველ რიგში, მას აკიდებს MPLS ეტიკეტს, რომელიც განსაზღვრავს დისტანციურ ინტერფეისს, ასე რომ, vRouter-ის უკანა მხარეს შეუძლია განსაზღვროს სად განთავსდეს ეს პაკეტი დამატებითი მოძიების გარეშე.

   

4. Tunnel0-ს აქვს წყარო 10.0.0.2, დანიშნულება: 10.0.1.2.
   vRouter ამატებს GRE (ან UDP) სათაურებს და ახალ IP-ს თავდაპირველ პაკეტს.
5. vRouter მარშრუტიზაციის ცხრილს აქვს ნაგულისხმევი მარშრუტი ToR1 მისამართის 10.0.0.1 მეშვეობით. სწორედ იქ აგზავნის.

   
   

6. ToR1-მა, როგორც Underlay ქსელის წევრმა, იცის (მაგალითად, OSPF-ის საშუალებით) როგორ მოხვდეს 10.0.1.2-მდე და აგზავნის პაკეტს მარშრუტის გასწვრივ. გაითვალისწინეთ, რომ ECMP აქ ჩართულია. ილუსტრაციაში არის ორი შემდეგი ჰოპი და სხვადასხვა ძაფები დალაგდება მათში ჰეშის მიხედვით. რეალური ქარხნის შემთხვევაში უფრო სავარაუდოა 4 შემდეგი ჰოპი.

   ამავდროულად, მას არ სჭირდება იცოდეს რა არის გარე IP სათაურის ქვეშ. ანუ, ფაქტობრივად, IP-ს ქვეშ შეიძლება იყოს IPv6 სენდვიჩი MPLS-ზე Ethernet-ზე MPLS-ზე GRE-ზე მეტი ბერძნულზე.

7. შესაბამისად, მიმღებ მხარეს, vRouter აშორებს GRE-ს და MPLS ტეგის გამოყენებით, ესმის, რომელ ინტერფეისზე უნდა გაიგზავნოს ეს პაკეტი, აშორებს მას და ორიგინალური სახით უგზავნის მიმღებს.

საკონტროლო თვითმფრინავი

როდესაც მანქანას ჩართავთ, იგივე ხდება, რაც ზემოთ იყო აღწერილი.

და პლუს შემდეგი:

• თითოეული კლიენტისთვის vRouter გამოყოფს MPLS ტეგს. ეს არის L3VPN სერვისის ეტიკეტი, რომლითაც კლიენტები გამოიყოფა იმავე ფიზიკურ მანქანაში.
  

  სინამდვილეში, MPLS ტეგი ყოველთვის უპირობოდ არის გამოყოფილი vRouter-ის მიერ - ყოველივე ამის შემდეგ, წინასწარ არ არის ცნობილი, რომ მანქანა მხოლოდ იმავე vRouter-ის მიღმა არსებულ სხვა მანქანებთან ურთიერთობს და ეს, სავარაუდოდ, არც კი შეესაბამება სიმართლეს.

• vRouter ამყარებს კავშირს SDN კონტროლერთან BGP პროტოკოლის გამოყენებით (ან მის მსგავსი - TF-ის შემთხვევაში, ეს არის XMPP 0_o).
• ამ სესიის მეშვეობით, vRouter აცნობებს მარშრუტებს დაკავშირებული ქსელებისკენ SDN კონტროლერთან:
  • ქსელის მისამართი
  • კაფსულაციის მეთოდი (MPLSoGRE, MPLSoUDP, VXLAN)
  • MPLS კლიენტის ტეგი
  • თქვენი IP მისამართი, როგორც nexthop

• SDN კონტროლერი იღებს ასეთ მარშრუტებს ყველა დაკავშირებული vRouter-იდან და ასახავს მათ სხვებს. ანუ ის მოქმედებს როგორც მარშრუტის ამრეკლი.

იგივე ხდება საპირისპირო მიმართულებით.

გადაფარვა შეიძლება შეიცვალოს ყოველ წუთში მაინც. ეს არის დაახლოებით ის, რაც ხდება საჯარო ღრუბლებში, სადაც კლიენტები რეგულარულად იწყებენ და წყვეტენ თავიანთ ვირტუალურ მანქანებს.

ცენტრალური კონტროლერი ზრუნავს ყველა სირთულეზე კონფიგურაციის შენარჩუნებისა და vRouter-ზე გადართვის/მარშრუტიზაციის ცხრილების მონიტორინგზე.

უხეშად რომ ვთქვათ, კონტროლერი აკავშირებს ყველა vRouter-თან BGP-ის (ან მსგავსი პროტოკოლის) მეშვეობით და უბრალოდ გადასცემს მარშრუტიზაციის ინფორმაციას. მაგალითად, BGP-ს უკვე აქვს Address-Family ინკაფსულაციის მეთოდის გადმოსაცემად MPLS-ში-GRE ან MPLS-ში-UDP.

ამავდროულად, Underlay ქსელის კონფიგურაცია არანაირად არ იცვლება, რაც, სხვათა შორის, ბევრად უფრო რთულია ავტომატიზირება და უხერხული მოძრაობით გატეხვა.

გასვლა გარე სამყაროში

სადღაც სიმულაცია უნდა დასრულდეს და თქვენ უნდა გახვიდეთ ვირტუალური სამყაროდან რეალურში. და თქვენ გჭირდებათ სატელეფონო კარიბჭე.

გამოიყენება ორი მიდგომა:

1. დამონტაჟებულია ტექნიკის როუტერი.
2. გაშვებულია მოწყობილობა, რომელიც ახორციელებს როუტერის ფუნქციებს (დიახ, SDN-ის შემდეგ, ჩვენ ასევე შევხვდით VNF-ს). მოდით ვუწოდოთ მას ვირტუალური კარიბჭე.

მეორე მიდგომის უპირატესობა არის იაფი ჰორიზონტალური მასშტაბურობა - არ არის საკმარისი სიმძლავრე - ჩვენ გავუშვით კიდევ ერთი ვირტუალური მანქანა კარიბჭით. ნებისმიერ ფიზიკურ მანქანაზე, უფასო თაროების, ერთეულების, ენერგიის გამომუშავების გარეშე, იყიდეთ თავად აპარატურა, გადაიტანეთ იგი, დააინსტალირეთ, გადართეთ, დააკონფიგურიროთ და შემდეგ ასევე შეცვალოთ მასში გაუმართავი კომპონენტები.

ვირტუალური კარიბჭის ნაკლოვანებები ის არის, რომ ფიზიკური როუტერის ერთეული ჯერ კიდევ უფრო ძლიერია, ვიდრე მრავალბირთვიანი ვირტუალური მანქანა და მისი პროგრამული უზრუნველყოფა, რომელიც მორგებულია საკუთარ აპარატურულ ბაზაზე, მუშაობს ბევრად უფრო სტაბილურად (არარის). ასევე ძნელია იმის უარყოფა, რომ აპარატურა და პროგრამული კომპლექსი უბრალოდ მუშაობს, მხოლოდ კონფიგურაციას მოითხოვს, ხოლო ვირტუალური კარიბჭის გაშვება და შენარჩუნება ძლიერი ინჟინრების ამოცანაა.

ერთი ფეხით, კარიბჭე უყურებს Overlay ვირტუალურ ქსელს, როგორც ჩვეულებრივი ვირტუალური მანქანა, და შეუძლია ურთიერთქმედება ყველა სხვა VM-თან. ამავდროულად, მას შეუძლია შეწყვიტოს ყველა კლიენტის ქსელი და, შესაბამისად, განახორციელოს მარშრუტიზაცია მათ შორის.

მეორე ფეხით კარიბჭე უყურებს საყრდენ ქსელს და იცის როგორ მოხვდეს ინტერნეტში.

მონაცემთა თვითმფრინავი

ანუ, პროცესი ასე გამოიყურება:

1. VM-0, რომელსაც ნაგულისხმევი აქვს იგივე vRouter, აგზავნის პაკეტს გარე სამყაროს დანიშნულებით (185.147.83.177) eth0 ინტერფეისში.
2. vRouter იღებს ამ პაკეტს და ეძებს დანიშნულების მისამართს მარშრუტიზაციის ცხრილში - პოულობს ნაგულისხმევ მარშრუტს VNGW1 კარიბჭის გავლით გვირაბის 1-ის გავლით.
   ის ასევე ხედავს, რომ ეს არის GRE გვირაბი SIP 10.0.0.2-ით და DIP 10.0.255.2-ით და მას ასევე ჯერ უნდა მიამაგროს ამ კლიენტის MPLS ეტიკეტები, რასაც VNGW1 მოელის.
3. vRouter ავსებს საწყის პაკეტს MPLS, GRE და ახალი IP სათაურებით და ნაგულისხმევად აგზავნის ToR1 10.0.0.1-ზე.
4. ძირითადი ქსელი აწვდის პაკეტს Gateway VNGW1-ში.
5. VNGW1 კარიბჭე შლის GRE და MPLS გვირაბის სათაურებს, ხედავს დანიშნულების მისამართს, კონსულტაციებს უწევს მის მარშრუტულ ცხრილს და ესმის, რომ ის მიმართულია ინტერნეტში - ანუ სრული ხედვის ან ნაგულისხმევის საშუალებით. საჭიროების შემთხვევაში, ასრულებს NAT თარგმანს.
6. შეიძლება არსებობდეს რეგულარული IP ქსელი VNGW-დან საზღვრამდე, რაც ნაკლებად სავარაუდოა.
   შეიძლება იყოს კლასიკური MPLS ქსელი (IGP+LDP/RSVP TE), შეიძლება იყოს უკანა ქსოვილი BGP LU-ით ან GRE გვირაბი VNGW-დან საზღვრამდე IP ქსელის საშუალებით.
   როგორც არ უნდა იყოს, VNGW1 ასრულებს აუცილებელ ინკაპსულაციებს და აგზავნის საწყის პაკეტს საზღვარზე.

მოძრაობა საპირისპირო მიმართულებით გადის იგივე საფეხურებით საპირისპირო თანმიმდევრობით.

1. საზღვრები ტოვებს პაკეტს VNGW1-ზე
2. ის ხსნის მას, ათვალიერებს მიმღების მისამართს და ხედავს, რომ ის ხელმისაწვდომია Tunnel1 გვირაბის მეშვეობით (MPLSoGRE ან MPLSoUDP).
3. შესაბამისად, ის ანიჭებს MPLS ეტიკეტს, GRE/UDP სათაურს და ახალ IP-ს და აგზავნის მას ToR3 10.0.255.1-ზე.
   გვირაბის დანიშნულების მისამართი არის vRouter-ის IP მისამართი, რომლის უკანაც მდებარეობს სამიზნე VM - 10.0.0.2.
4. ძირითადი ქსელი აწვდის პაკეტს სასურველ vRouter-ზე.
5. სამიზნე vRouter კითხულობს GRE/UDP, განსაზღვრავს ინტერფეისს MPLS ეტიკეტის გამოყენებით და აგზავნის შიშველი IP პაკეტს თავის TAP ინტერფეისში, რომელიც ასოცირდება VM-ის eth0-თან.

საკონტროლო თვითმფრინავი

VNGW1 აყალიბებს BGP სამეზობლოს SDN კონტროლერთან, საიდანაც იღებს ყველა მარშრუტულ ინფორმაციას კლიენტების შესახებ: რომელი IP მისამართი (vRouter) არის რომელი კლიენტის უკან და რომელი MPLS ლეიბლით არის იდენტიფიცირებული.

ანალოგიურად, ის თავად აცნობებს SDN კონტროლერს ნაგულისხმევი მარშრუტის შესახებ ამ კლიენტის ეტიკეტით, რომელიც მიუთითებს საკუთარ თავს, როგორც nexthop. და შემდეგ ეს ნაგულისხმევი მიდის vRouters-ზე.

VNGW-ზე ჩვეულებრივ ხდება მარშრუტის აგრეგაცია ან NAT თარგმანი.

და სხვა მიმართულებით, ის აგზავნის ზუსტად ამ აგრეგირებულ მარშრუტს სესიაზე საზღვრებით ან მარშრუტის ამრეკლებით. და მათგან იღებს ნაგულისხმევ მარშრუტს ან Full-View, ან სხვა რამეს.

ინკაფსულაციისა და ტრაფიკის გაცვლის თვალსაზრისით, VNGW არაფრით განსხვავდება vRouter-ისგან.
თუ ოდნავ გააფართოვებთ ფარგლებს, მაშინ შეგიძლიათ დაამატოთ სხვა ქსელური მოწყობილობები VNGW-ებსა და vRouters-ში, როგორიცაა firewalls, ტრაფიკის გაწმენდა ან გამდიდრების ფერმები, IPS და ა.შ.

და VRF-ების თანმიმდევრული შექმნისა და მარშრუტების სწორად გამოცხადების დახმარებით, თქვენ შეგიძლიათ აიძულოთ ტრაფიკი დაარეგულიროთ ისე, როგორც გსურთ, რასაც Service Chaining ჰქვია.

ანუ, აქაც SDN კონტროლერი მოქმედებს როგორც მარშრუტი-რეფლექტორი VNGW-ებს, vRouters-სა და სხვა ქსელურ მოწყობილობებს შორის.

მაგრამ სინამდვილეში, კონტროლერი ასევე გაჟონავს ინფორმაციას ACL და PBR (პოლიტიკაზე დაფუძნებული მარშრუტი) შესახებ, რის გამოც ინდივიდუალური მოძრაობის ნაკადები განსხვავებულად მიმდინარეობს, ვიდრე მარშრუტი ეუბნება მათ.

კითხვა-პასუხი

რატომ აკეთებთ ყოველთვის GRE/UDP შენიშვნას?

ზოგადად, შეიძლება ითქვას, რომ ეს სპეციფიკურია ვოლფრამის ქსოვილისთვის - თქვენ საერთოდ არ გჭირდებათ ამის გათვალისწინება.

მაგრამ თუ ავიღებთ ამას, თავად TF, მიუხედავად იმისა, რომ ჯერ კიდევ OpenContrail იყო, მხარს უჭერდა ორივე კაფსულაციას: MPLS GRE-ში და MPLS UDP-ში.

UDP კარგია, რადგან წყაროს პორტში ძალიან მარტივია ჰეშის ფუნქციის დაშიფვრა ორიგინალური IP+Proto+პორტიდან მის სათაურში, რაც საშუალებას მოგცემთ გააკეთოთ დაბალანსება.

GRE-ის შემთხვევაში, სამწუხაროდ, არის მხოლოდ გარე IP და GRE სათაურები, რომლებიც ერთნაირია ყველა ჩაკეტილი ტრაფიკისთვის და საუბარი არ არის დაბალანსებაზე - ცოტას შეუძლია პაკეტში ასე ღრმად ჩახედვა.

გარკვეული პერიოდის განმავლობაში, მარშრუტიზატორებმა, თუ იცოდნენ როგორ გამოიყენონ დინამიური გვირაბები, ამას აკეთებდნენ მხოლოდ MPLSoGRE-ში და მხოლოდ ახლახან ისწავლეს MPLSoUDP-ის გამოყენება. ამიტომ, ჩვენ ყოველთვის უნდა გავაკეთოთ შენიშვნა ორი განსხვავებული ინკაფსულაციის შესაძლებლობის შესახებ.

სამართლიანობისთვის, აღსანიშნავია, რომ TF სრულად უჭერს მხარს L2 დაკავშირებას VXLAN-ის გამოყენებით.

თქვენ დაგპირდით პარალელების გავლებას OpenFlow-თან.
ამას ნამდვილად ითხოვენ. vSwitch იმავე OpenStack-ში აკეთებს ძალიან მსგავს რაღაცეებს, VXLAN-ის გამოყენებით, რომელსაც, სხვათა შორის, ასევე აქვს UDP სათაური.

მონაცემთა სიბრტყეში ისინი დაახლოებით ერთნაირად მუშაობენ; საკონტროლო სიბრტყე მნიშვნელოვნად განსხვავდება. ვოლფრამის ქსოვილი იყენებს XMPP-ს მარშრუტიზაციის ინფორმაციის გადასაცემად vRouter-ში, ხოლო OpenStack აწარმოებს Openflow-ს.

შეგიძლიათ ცოტა მეტი მითხრათ vRouter-ის შესახებ?
ის იყოფა ორ ნაწილად: vRouter Agent და vRouter Forwarder.

პირველი მუშაობს მასპინძელი OS-ის მომხმარებლის სივრცეში და ურთიერთობს SDN კონტროლერთან, ცვლის ინფორმაციას მარშრუტების, VRF-ების და ACL-ების შესახებ.

მეორე ახორციელებს Data Plane - ჩვეულებრივ Kernel Space-ში, მაგრამ ასევე შეიძლება იმუშაოს SmartNIC-ებზე - ქსელის ბარათები CPU-ით და ცალკე პროგრამირებადი გადართვის ჩიპით, რომელიც საშუალებას გაძლევთ ამოიღოთ დატვირთვა მასპინძელი მანქანის CPU-დან და გახადოთ ქსელი უფრო სწრაფი და მეტი. პროგნოზირებადი.

კიდევ ერთი შესაძლო სცენარი არის ის, რომ vRouter არის DPDK აპლიკაცია მომხმარებლის სივრცეში.

vRouter Agent უგზავნის პარამეტრებს vRouter Forwarder-ს.

რა არის ვირტუალური ქსელი?
VRF-ის შესახებ სტატიის დასაწყისში აღვნიშნე, რომ თითოეული მოიჯარე მიბმულია საკუთარ VRF-თან. და თუ ეს საკმარისი იყო გადაფარვის ქსელის მუშაობის ზედაპირული გაგებისთვის, მაშინ მომდევნო გამეორებისას აუცილებელია განმარტებების გაკეთება.

როგორც წესი, ვირტუალიზაციის მექანიზმებში ვირტუალური ქსელის ერთეული (შეგიძლიათ ჩათვალოთ ეს საკუთრივ არსებითი სახელი) ინერგება კლიენტებისგან/მოიჯარეების/ვირტუალური მანქანებისგან განცალკევებით - სრულიად დამოუკიდებელი რამ. და ეს ვირტუალური ქსელი უკვე შეიძლება დაუკავშირდეს ინტერფეისების მეშვეობით ერთ მოიჯარეს, მეორეს, ორს ან სადმე. მაგალითად, Service Chaining ხორციელდება მაშინ, როდესაც ტრაფიკი უნდა გაიაროს გარკვეული კვანძების მეშვეობით საჭირო თანმიმდევრობით, უბრალოდ ვირტუალური ქსელების სწორი თანმიმდევრობით შექმნით და დაკავშირებით.

ამიტომ, როგორც ასეთი, არ არსებობს პირდაპირი მიმოწერა ვირტუალურ ქსელსა და მოიჯარეს შორის.

დასკვნა

ეს არის ვირტუალური ქსელის ფუნქციონირების ძალიან ზედაპირული აღწერა ჰოსტიდან და SDN კონტროლერის გადაფარვით. მაგრამ არ აქვს მნიშვნელობა რომელ ვირტუალიზაციის პლატფორმას აირჩევთ დღეს, ის იმუშავებს ანალოგიურად, იქნება ეს VMWare, ACI, OpenStack, CloudStack, ვოლფრამის ქსოვილი თუ Juniper Contrail. ისინი განსხვავდებიან ინკაპსულაციებისა და სათაურების ტიპებში, ბოლო ქსელის მოწყობილობებზე ინფორმაციის მიწოდების პროტოკოლებში, მაგრამ პროგრამული უზრუნველყოფის კონფიგურირებადი გადაფარვის ქსელის პრინციპი, რომელიც მუშაობს შედარებით მარტივი და სტატიკური ქვედა ქსელის თავზე, იგივე დარჩება.
შეგვიძლია ვთქვათ, რომ დღეს გადაფარვის ქსელზე დაფუძნებულმა SDN-მა მოიგო კერძო ღრუბლის შექმნის სფერო. თუმცა ეს არ ნიშნავს, რომ Openflow-ს ადგილი არ აქვს თანამედროვე სამყაროში - გამოიყენება OpenStacke-ში და იგივე VMWare NSX-ში, როგორც ვიცი, Google იყენებს მას მიწისქვეშა ქსელის დასაყენებლად.

ქვემოთ მოყვანილი მაქვს უფრო დეტალური მასალების ბმულები, თუ გსურთ საკითხის უფრო ღრმად შესწავლა.

და რაც შეეხება ჩვენს საყრდენს?

მაგრამ ზოგადად, არაფერი. მან მთელი გზა არ შეცვალა. ყველაფერი, რაც მან უნდა გააკეთოს ჰოსტის მხრიდან გადაფარვის შემთხვევაში, არის მარშრუტებისა და ARP-ების განახლება, რადგან vRouter/VNGW გამოჩნდება და ქრება და ატარებს პაკეტებს მათ შორის.

მოდით ჩამოვაყალიბოთ Underlay ქსელის მოთხოვნების სია.

1. შეგეძლოთ გამოიყენოთ რაიმე სახის მარშრუტიზაციის პროტოკოლი, ჩვენს სიტუაციაში - BGP.
2. გქონდეთ ფართო გამტარობა, სასურველია ზედმეტი გამოწერის გარეშე, რათა პაკეტები არ დაიკარგოს გადატვირთვის გამო.
3. ECMP-ის მხარდაჭერა ქსოვილის განუყოფელი ნაწილია.
4. შეძლოთ QoS-ის მიწოდება, მათ შორის ისეთი რთული საკითხების ჩათვლით, როგორიცაა ECN.
5. NETCONF-ის მხარდაჭერა მომავლის საფუძველია.

აქ ძალიან ცოტა დრო დავუთმე თავად Underlay ქსელის მუშაობას. ეს იმიტომ ხდება, რომ სერიების შემდეგ მე მასზე გავამახვილებ ყურადღებას და მხოლოდ ზედმეტად შევეხებით Overlay-ს.

ცხადია, მე მკაცრად ვზღუდავ ყველას, მაგალითად ვიყენებ DC ქსელს, რომელიც აშენებულია Cloz ქარხანაში სუფთა IP მარშრუტირებით და მასპინძლის გადაფარვით.

თუმცა, დარწმუნებული ვარ, რომ ნებისმიერი ქსელი, რომელსაც აქვს დიზაინი, შეიძლება იყოს აღწერილი ფორმალური თვალსაზრისით და ავტომატიზირებული. უბრალოდ, ჩემი მიზანი აქ არის ავტომატიზაციის მიდგომების გააზრება და არა ყველას დაბნეულობა პრობლემის ზოგადი ფორმით გადაჭრით.

ADSM-ის ფარგლებში, მე და რომან ჯორჯი ვგეგმავთ გამოვაქვეყნოთ ცალკე გამოცემა გამოთვლითი სიმძლავრის ვირტუალიზაციისა და ქსელის ვირტუალიზაციასთან მისი ურთიერთქმედების შესახებ. Არ დაიკარგო.

სასარგებლო ბმულები

• ვოლფრამის ქსოვილის არქიტექტურა.
• შესახებ: ღრუბელი. 6 საათი Yandex.Cloud-ის შესახებ, რომელიც ასევე მოიცავს ვირტუალურ ქსელს TF-ზე.
• რა არის Open vSwitch?
• შესავალი VxLAN-ში.
• RFC 7348. ვირტუალური გაფართოებადი ლოკალური ქსელი (VXLAN): ჩარჩო ვირტუალიზებული ფენის 2 ქსელების გადაფარვისთვის 3 ფენის ქსელებზე.
  
• Scaleway მიდგომა VXLAN EVPN ქსოვილთან. იგი საუბრობს მთელ DC ქსელზე, მათ შორის Underlay, Overlay, მიდგომებზე მრავალ სახლში და მართვაზე.

Გმადლობთ

• რომან გორგა - linkmeup პოდკასტის ყოფილი წამყვანი და ახლა ღრუბლოვანი პლატფორმების დარგის ექსპერტი. კომენტარებისა და რედაქტირებისთვის. ისე, უახლოეს მომავალში ველოდებით მის უფრო ღრმა სტატიას ვირტუალიზაციის შესახებ.
• ალექსანდრე შალიმოვი - ჩემი კოლეგა და ექსპერტი ვირტუალური ქსელის განვითარების სფეროში. კომენტარებისა და რედაქტირებისთვის.
• ვალენტინ სინიცინი - ჩემი კოლეგა და ექსპერტი ვოლფრამის ქსოვილის დარგში. კომენტარებისა და რედაქტირებისთვის.
• არტიომ ჩერნობაი - ილუსტრატორის ლინკი. KDPV-სთვის.
• ალექსანდრე ლიმონოვი. "ავტომატური" მემისთვის.

წყარო: www.habr.com