🥇Cloud යටිතල ව්‍යූහයේ ජාල කොටස හැඳින්වීම

ක්ලවුඩ් කම්පියුටින් අපගේ ජීවිතයට ගැඹුරින් හා ගැඹුරට විනිවිද යන අතර අවම වශයෙන් එක් වරක්වත් කිසිදු ක්ලවුඩ් සේවාවක් භාවිතා නොකළ තනි පුද්ගලයෙක් නැත. කෙසේ වෙතත්, වලාකුළක් යනු කුමක්ද සහ එය ක්‍රියා කරන ආකාරය, අදහසක් මට්ටමින් පවා ස්වල්ප දෙනෙක් දනිති. 5G දැනටමත් යථාර්ථයක් වෙමින් පවතින අතර ටෙලිකොම් යටිතල ව්‍යුහය ධ්‍රැව විසඳුම්වල සිට වලාකුළු විසඳුම් දක්වා ගමන් කිරීමට පටන් ගෙන ඇත, එය සම්පූර්ණ දෘඩාංග විසඳුම්වල සිට අථත්‍යකරණය කළ “කුළුණු” වෙත මාරු වූවාක් මෙන්.

Сегодня поговорим о внутреннем мире облачной инфраструктуре, в частности разберем основы сетевой части.

Что такое облако? Та же виртуализация — вид в профиль?

තාර්කික ප්‍රශ්නයකට වඩා. නැත - මෙය අථත්‍යකරණය නොවේ, එය නොමැතිව කළ නොහැකි වුවද. අපි අර්ථ දැක්වීම් දෙකක් බලමු:

Cloud Computing (මෙතැන් සිට Cloud ලෙස හැඳින්වේ) සේවා සපයන්නාට හැකි අවම ප්‍රමාදයක් සහ අවම පිරිවැයක් සහිතව ඉල්ලුම මත යෙදවිය යුතු සහ දියත් කළ යුතු බෙදා හරින ලද පරිගණක සම්පත් වෙත පරිශීලක-හිතකාමී ප්‍රවේශයක් සැපයීමේ ආදර්ශයකි.

අථත්යකරණය - මෙය එක් භෞතික වස්තුවක් (උදාහරණයක් ලෙස, සේවාදායකයක්) අථත්‍ය ඒවා කිහිපයකට බෙදීමේ හැකියාවයි, එමඟින් සම්පත් භාවිතය වැඩි කරයි (උදාහරණයක් ලෙස, ඔබට සේවාදායකයන් 3 ක් සියයට 25-30 ට පටවා තිබුණි, අථත්‍යකරණයෙන් පසු ඔබට සේවාදායකයක් 1 ක් පටවනු ලැබේ. සියයට 80-90). ස්වාභාවිකවම, අථත්‍යකරණය සමහර සම්පත් අනුභව කරයි - ඔබ හයිපර්වයිසර් පෝෂණය කළ යුතුය, කෙසේ වෙතත්, ප්‍රායෝගිකව පෙන්වා දී ඇති පරිදි, ක්‍රීඩාව ඉටිපන්දම වටී. අථත්‍යකරණය සඳහා කදිම උදාහරණයක් වන්නේ VMWare, එය අථත්‍ය යන්ත්‍ර පරිපූර්ණ ලෙස සකස් කරයි, නැතහොත් උදාහරණයක් ලෙස KVM, මම කැමති නමුත් මෙය රසය පිළිබඳ කාරණයකි.

අපි එය අවබෝධ කර නොගෙන අථත්‍යකරණය භාවිතා කරන අතර යකඩ රවුටර පවා දැනටමත් අථත්‍යකරණය භාවිතා කරයි - නිදසුනක් ලෙස, ජූනෝස් හි නවතම අනුවාදයේ, මෙහෙයුම් පද්ධතිය තත්‍ය කාලීන ලිනක්ස් බෙදා හැරීමක් (වින්ඩ් රිවර් 9) මත අථත්‍ය යන්ත්‍රයක් ලෙස ස්ථාපනය කර ඇත. නමුත් අථත්‍යකරණය යනු වලාකුළ නොවේ, නමුත් අථත්‍යකරණයකින් තොරව වලාකුළට පැවතිය නොහැක.

අථත්‍යකරණය යනු වලාකුළ ගොඩනගා ඇති ගොඩනැඟිලි කොටස් වලින් එකකි.

සරලව එක් L2 වසමකට හයිපර්වයිසර් කිහිපයක් එකතු කිරීමෙන් වලාකුළක් සෑදීම, යම් ආකාරයක ඇන්සිබල් හරහා ස්වයංක්‍රීයව vlans ලියාපදිංචි කිරීම සඳහා yaml playbooks කිහිපයක් එකතු කිරීම සහ ස්වයංක්‍රීයව අථත්‍ය යන්ත්‍ර සෑදීම සඳහා වාද්‍ය වෘන්ද පද්ධතියක් වැනි දෙයක් එයට උඩින් තැබීම ක්‍රියා නොකරනු ඇත. එය වඩාත් නිවැරදි වනු ඇත, නමුත් ප්‍රතිඵලයක් ලෙස ලැබෙන ෆ්‍රැන්කන්ස්ටයින් අපට අවශ්‍ය වලාකුළ නොවේ, නමුත් එය අන් අයගේ අවසාන සිහිනය විය හැකිය. එපමණක් නොව, ඔබ එකම Openstack ගතහොත්, එය අත්‍යවශ්‍යයෙන්ම තවමත් ෆ්‍රැන්කන්ස්ටයින් වේ, නමුත් හොඳයි, අපි දැන් ඒ ගැන කතා නොකරමු.

නමුත් ඉහත ඉදිරිපත් කර ඇති නිර්වචනයෙන් ඇත්ත වශයෙන්ම වලාකුළක් ලෙස හැඳින්විය හැක්කේ කුමක්ද යන්න සම්පූර්ණයෙන්ම පැහැදිලි නැති බව මට වැටහේ.

එබැවින්, NIST (ජාතික ප්‍රමිති සහ තාක්ෂණ ආයතනය) හි ලේඛනයක් වලාකුළු යටිතල ව්‍යුහයකට තිබිය යුතු ප්‍රධාන ලක්ෂණ 5 ක් සපයයි:

ඉල්ලීම මත සේවා සැපයීම. පරිශීලකයාට ඔහුට වෙන් කර ඇති පරිගණක සම්පත් වෙත නොමිලේ ප්‍රවේශය ලබා දිය යුතුය (ජාල, අතථ්‍ය තැටි, මතකය, ප්‍රොසෙසර් කෝර් ආදිය), සහ මෙම සම්පත් ස්වයංක්‍රීයව සැපයිය යුතුය - එනම් සේවා සපයන්නාගේ මැදිහත්වීමකින් තොරව.

පුළුල් ලෙස ලබා ගත හැකි සේවාව. සම්මත පරිගණක සහ තුනී සේවාලාභීන් සහ ජංගම උපාංග යන දෙකම භාවිතා කිරීමට ඉඩ සලසන සම්මත යාන්ත්‍රණ මගින් සම්පත් වෙත ප්‍රවේශය සැපයිය යුතුය.

සම්පත් සංචිතවලට ඒකාබද්ධ කිරීම. සේවාලාභීන් හුදකලා වීම සහ සම්පත් සඳහා අන්‍යෝන්‍ය බලපෑමෙන් සහ තරඟකාරිත්වයෙන් තොර බව සහතික කරමින්, එකවර සේවාලාභීන් කිහිප දෙනෙකුට සම්පත් සැපයීමට සම්පත් සංචිතවලට හැකි විය යුතුය. ජාල ද තටාකවල ඇතුළත් කර ඇති අතර, එය අතිච්ඡාදනය වන ලිපින භාවිතා කිරීමේ හැකියාව පෙන්නුම් කරයි. තටාක ඉල්ලුම මත පරිමාණය කිරීමට හැකි විය යුතුය. තටාක භාවිතය මඟින් සම්පත් දෝෂ ඉවසීමේ අවශ්‍ය මට්ටම සහ භෞතික හා අතථ්‍ය සම්පත් වියුක්ත කිරීම සැපයීමට හැකි වේ - සේවාව ලබන්නාට ඔහු ඉල්ලා සිටි සම්පත් කට්ටලය සරලව සපයනු ලැබේ (මෙම සම්පත් භෞතිකව පිහිටා ඇති ස්ථාන, කොපමණ මත සේවාදායකයන් සහ ස්විචයන් - එය සේවාදායකයාට වැදගත් නොවේ). කෙසේ වෙතත්, සැපයුම්කරු විසින් මෙම සම්පත් විනිවිද පෙනෙන ලෙස වෙන් කිරීම සහතික කළ යුතු බව අප සැලකිල්ලට ගත යුතුය.

විවිධ තත්වයන්ට ඉක්මන් අනුවර්තනය වීම. Сервисы должны быть гибкими — быстрое предоставление ресурсов, их перераспределение, добавление или сокращение ресурсов по запросу клиента, причем со стороны клиента должно складываться ощущение, что ресурсы облака бесконечны. Для простоты понимания, например, вы же не видите предупреждение о том, что у вас в Apple iCloud пропала часть дискового пространства из за того, что на сервере сломался жесткий диск, а диски то ломаются. К тому же с вашей стороны возможности этого сервиса практически безграничны — нужно вам 2 Тб — не проблема, заплатили и получили. Аналогично можно привести пример с Google.Drive или Yandex.Disk.

සපයනු ලබන සේවාව මැනීමේ හැකියාව. ක්ලවුඩ් පද්ධති පරිභෝජන සම්පත් ස්වයංක්‍රීයව පාලනය කර ප්‍රශස්ත කළ යුතු අතර, මෙම යාන්ත්‍රණයන් පරිශීලකයාට සහ සේවා සපයන්නාට පාරදෘශ්‍ය විය යුතුය. එනම්, ඔබ සහ ඔබේ ගනුදෙනුකරුවන් කොපමණ සම්පත් පරිභෝජනය කරනවාද යන්න ඔබට සැමවිටම පරීක්ෂා කළ හැකිය.

මෙම අවශ්‍යතා බොහෝ දුරට පොදු වලාකුළක් සඳහා වන අවශ්‍යතා සලකා බැලීම වටී, එබැවින් පුද්ගලික වලාකුළක් සඳහා (එනම් සමාගමේ අභ්‍යන්තර අවශ්‍යතා සඳහා දියත් කරන ලද වලාකුළක්), මෙම අවශ්‍යතා තරමක් සකස් කළ හැකිය. කෙසේ වෙතත්, ඔවුන් තවමත් සිදු කළ යුතු අතර, එසේ නොමැති නම් අපි Cloud computing හි සියලු ප්රතිලාභ ලබා නොගනු ඇත.

අපට වලාකුළක් අවශ්‍ය වන්නේ ඇයි?

කෙසේ වෙතත්, ඕනෑම නව හෝ පවතින තාක්‍ෂණයක්, ඕනෑම නව ප්‍රොටෝකෝලය යමක් සඳහා නිර්මාණය කර ඇත (හොඳයි, RIP-ng හැර, ඇත්ත වශයෙන්ම). ප්‍රොටෝකෝලයක් සඳහා කිසිවෙකුට ප්‍රොටෝකෝලයක් අවශ්‍ය නොවේ (හොඳයි, RIP-ng හැර, ඇත්ත වශයෙන්ම). පරිශීලකයාට/සේවාදායකයාට යම් ආකාරයක සේවාවක් සැපයීම සඳහා Cloud නිර්මාණය කර ඇති බව තර්කානුකූලයි. අපි හැමෝම අවම වශයෙන් වලාකුළු සේවා කිහිපයක් ගැන හුරුපුරුදුය, උදාහරණයක් ලෙස Dropbox හෝ Google.Docs, සහ මම විශ්වාස කරනවා බොහෝ අය ඒවා සාර්ථකව භාවිතා කරන බව - උදාහරණයක් ලෙස, මෙම ලිපිය ලියා ඇත්තේ Google.Docs Cloud සේවාව භාවිතා කරමිනි. නමුත් අප දන්නා වලාකුළු සේවා වලාකුළේ හැකියාවන්ගෙන් කොටසක් පමණි - වඩාත් නිවැරදිව, ඒවා SaaS වර්ගයේ සේවාවක් පමණි. අපට වලාකුළු සේවාවක් ආකාර තුනකින් සැපයිය හැකිය: SaaS, PaaS හෝ IaaS ආකාරයෙන්. ඔබට අවශ්ය සේවාව ඔබගේ ආශාවන් සහ හැකියාවන් මත රඳා පවතී.

අපි එක් එක් පිළිවෙලට බලමු:

සේවාවක් ලෙස මෘදුකාංගය (SaaS) සේවාලාභියාට පූර්ණ-පරිපූර්ණ සේවාවක් සැපයීම සඳහා ආදර්ශයකි, උදාහරණයක් ලෙස, Yandex.Mail හෝ Gmail වැනි ඊමේල් සේවාවක්. මෙම සේවා බෙදා හැරීමේ ආකෘතිය තුළ, ඔබ, සේවාලාභියෙකු ලෙස, සේවා භාවිතා කිරීම හැර අන් කිසිවක් නොකෙරේ - එනම්, සේවාව පිහිටුවීම, එහි වැරදි ඉවසීම හෝ අතිරික්තය ගැන ඔබ සිතිය යුතු නැත. ප්රධාන දෙය නම් ඔබගේ මුරපදය සම්මුතියක් නොකිරීමයි; මෙම සේවාව සපයන්නා ඔබ වෙනුවෙන් ඉතිරි දේ කරනු ඇත. සේවා සපයන්නාගේ දෘෂ්ටි කෝණයෙන්, ඔහු සම්පූර්ණ සේවාව සඳහා සම්පූර්ණ වගකීම දරයි - සේවාදායක දෘඪාංග සහ ධාරක මෙහෙයුම් පද්ධති සිට දත්ත සමුදාය සහ මෘදුකාංග සැකසුම් දක්වා.

සේවාවක් ලෙස වේදිකාව (PaaS) — при использовании данной модели поставщик услуг предоставляет клиенту заготовку под сервис, например возьмем Web сервер. Поставщик услуг предоставил клиенту виртуальный сервер (по факту набор ресурсов, таких как RAM/CPU/Storage/Nets и т д), и даже установил на данный сервер ОС и необходимое ПО, однако настройку всего этого добра производит сам клиент и за работоспособность сервиса уже отвечает клиент. Поставщик услуг, как и в прошлом случае отвечает за работоспособность физического оборудования, гипервизоров, самой виртуальной машины, ее сетевую доступность и т д, но сам сервис уже вне его зоны ответственности.

සේවාවක් ලෙස යටිතල පහසුකම් (IaaS) - මෙම ප්‍රවේශය දැනටමත් වඩාත් සිත්ගන්නා සුළුය, ඇත්ත වශයෙන්ම, සේවා සපයන්නා විසින් සේවාදායකයාට සම්පූර්ණ අථත්‍ය යටිතල පහසුකම් සපයයි - එනම්, CPU Cores, RAM, Networks වැනි සම්පත් සමූහයක් (සංචිතයක්) අනෙක් සියල්ල දක්වා ඇත. සේවාලාභියා - වෙන් කළ සංචිතය (කෝටාව) තුළ මෙම සම්පත් සමඟ සේවාදායකයාට කිරීමට අවශ්‍ය දේ - එය සැපයුම්කරුට විශේෂයෙන් වැදගත් නොවේ. සේවාදායකයාට තමාගේම vEPC නිර්මාණය කිරීමට අවශ්‍යද නැතහොත් කුඩා ක්‍රියාකරුවෙකු නිර්මාණය කර සන්නිවේදන සේවා සැපයීමට අවශ්‍යද යන්න - ප්‍රශ්නයක් නැත - එය කරන්න. එවැනි තත්වයක් තුළ, සම්පත් සැපයීම, ඒවායේ වැරදි ඉවසීම සහ ලබා ගැනීමේ හැකියාව මෙන්ම, මෙම සම්පත් එකතු කිරීමට සහ ඕනෑම අවස්ථාවක සම්පත් වැඩි කිරීමට හෝ අඩු කිරීමට හැකියාව ඇති සේවාදායකයාට ලබා දීමට ඉඩ සලසන මෙහෙයුම් පද්ධතිය සඳහා සේවා සපයන්නා වගකිව යුතුය. සේවාදායකයාගේ ඉල්ලීම මත. සේවාලාභියා විසින් ජාල පිහිටුවීම (බාහිර ජාල හැර) ඇතුළුව ස්වයං සේවා ද්වාරය සහ කොන්සෝලය හරහා සියලුම අතථ්‍ය යන්ත්‍ර සහ අනෙකුත් ටින්සල් වින්‍යාස කරයි.

OpenStack යනු කුමක්ද?

විකල්ප තුනෙහිම, සේවා සපයන්නාට වලාකුළු යටිතල පහසුකම් නිර්මාණය කිරීමට හැකි වන මෙහෙයුම් පද්ධතියක් අවශ්‍ය වේ. ඇත්ත වශයෙන්ම, SaaS සමඟ, සමස්ත තාක්‍ෂණ තොගයට එක් අංශයකට වඩා වගකිව යුතුය - යටිතල පහසුකම් සඳහා වගකිව යුතු අංශයක් ඇත - එනම්, එය වෙනත් අංශයකට IaaS සපයයි, මෙම අංශය සේවාදායකයාට SaaS සපයයි. OpenStack යනු ඔබට ස්විචයන්, සර්වර් සහ ගබඩා පද්ධති සමූහයක් එක් සම්පත් සංචිතයකට එකතු කිරීමටත්, මෙම පොදු සංචිතය subpools (කුලී නිවැසියන්) බවට බෙදීමට සහ ජාලය හරහා සේවාදායකයින්ට මෙම සම්පත් ලබා දීමටත් ඉඩ සලසන ක්ලවුඩ් මෙහෙයුම් පද්ධති වලින් එකකි.

OpenStack — это облачная операционная система которая позволяет контролировать большие пулы вычислительных ресурсов, хранилищ данных и сетевых ресурсов, провижининг и управление которыми производится через API с использованием стандартных механизмов аутентификации.

වෙනත් වචන වලින් කිවහොත්, මෙය වලාකුළු සේවා (පොදු සහ පුද්ගලික යන දෙකම) නිර්මාණය කිරීම සඳහා නිර්මාණය කර ඇති නිදහස් මෘදුකාංග ව්‍යාපෘති සමූහයකි - එනම්, සේවාදායකය සහ මාරු කිරීමේ උපකරණ තනි සම්පත් සංචිතයකට ඒකාබද්ධ කිරීමට, කළමනාකරණය කිරීමට ඔබට ඉඩ සලසන මෙවලම් සමූහයකි. මෙම සම්පත්, වැරදි ඉවසීමේ අවශ්‍ය මට්ටම ලබා දෙයි.

මෙම ද්‍රව්‍යය ලියන අවස්ථාවේදී, OpenStack ව්‍යුහය මේ ආකාරයට පෙනේ:

Картинка взята с openstack.org

OpenStack හි ඇතුළත් සෑම සංරචකයක්ම නිශ්චිත කාර්යයක් ඉටු කරයි. මෙම බෙදා හරින ලද ගෘහ නිර්මාණ ශිල්පය ඔබට අවශ්‍ය ක්‍රියාකාරී සංරචක කට්ටලය විසඳුමට ඇතුළත් කිරීමට ඉඩ සලසයි. කෙසේ වෙතත්, සමහර සංරචක මූල සංරචක වන අතර ඒවා ඉවත් කිරීම සමස්තයක් ලෙස විසඳුමේ සම්පූර්ණ හෝ අර්ධ අක්‍රියතාවයට හේතු වේ. මෙම සංරචක සාමාන්යයෙන් වර්ගීකරණය කර ඇත:

උපකරණ පුවරුව - OpenStack සේවා කළමනාකරණය සඳහා වෙබ් පාදක GUI
Keystone — централизованный сервис идентификации, который предоставляет функциональность аутентификации и авторизации для других сервисов, а также управлять учетными данными пользователей и их ролями.
නියුට්‍රෝන - විවිධ OpenStack සේවාවන්හි අතුරුමුහුණත් අතර සම්බන්ධතාවය සපයන ජාල සේවාවක් (VM අතර සම්බන්ධතාවය සහ බාහිර ලෝකයට ප්‍රවේශ වීම ඇතුළුව)
සින්ඩර් — предоставляет доступ к блочному хранилищу для виртуальных машин
නෝවා - අතථ්‍ය යන්ත්‍රවල ජීවන චක්‍ර කළමනාකරණය
බැලූ බැල්මට — අතථ්‍ය යන්ත්‍ර රූප සහ ස්නැප්ෂොට් ගබඩාව
ඉක්මන් - ගබඩා වස්තුව වෙත ප්රවේශය සපයයි
සියිලෝමීටරය — служба, предоставляющая возможность сбора телеметрии и замера имеющихся и поребляющих ресурсов
තාපය - ස්වයංක්‍රීයව නිර්මාණය කිරීම සහ සම්පත් සැපයීම සඳහා සැකිලි මත පදනම් වූ වාද්‍ය වෘන්දය

සියලුම ව්යාපෘතිවල සම්පූර්ණ ලැයිස්තුවක් සහ ඒවායේ අරමුණ නැරඹිය හැකිය මෙහි.

සෑම OpenStack සංරචකයක්ම නිශ්චිත කාර්යයක් ඉටු කරන සේවාවක් වන අතර එම කාර්යය කළමනාකරණය කිරීමට සහ අනෙකුත් ක්ලවුඩ් මෙහෙයුම් පද්ධති සේවාවන් සමඟ ඒකාබද්ධ යටිතල පහසුකම් නිර්මාණය කිරීමට API සපයයි. උදාහරණයක් ලෙස, Nova මෙම සම්පත් වින්‍යාස කිරීමට ප්‍රවේශය සඳහා පරිගණක සම්පත් කළමනාකරණය සහ API සපයයි, Glance රූප කළමනාකරණය සහ ඒවා කළමනාකරණය කිරීම සඳහා API සපයයි, Cinder බ්ලොක් ගබඩාව සහ එය කළමනාකරණය සඳහා API සපයයි. සියලුම කාර්යයන් ඉතා සමීප ආකාරයකින් එකිනෙකට සම්බන්ධ වේ.

කෙසේ වෙතත්, ඔබ එය දෙස බැලුවහොත්, OpenStack හි ක්‍රියාත්මක වන සියලුම සේවාවන් අවසානයේ ජාලයට සම්බන්ධ යම් ආකාරයක අථත්‍ය යන්ත්‍රයක් (හෝ බහාලුම්) වේ. ප්රශ්නය පැනනගින්නේ - අපට බොහෝ මූලද්රව්ය අවශ්ය වන්නේ ඇයි?

අතථ්‍ය යන්ත්‍රයක් සාදා එය ජාලයට සම්බන්ධ කිරීම සහ Openstack හි ස්ථිර ගබඩා කිරීම සඳහා ඇල්ගොරිතම හරහා යමු.

ඔබ යන්ත්‍රයක් සෑදීමට ඉල්ලීමක් සාදන විට, එය Horizon (Dashboard) හරහා ඉල්ලීමක් හෝ CLI හරහා ඉල්ලීමක් වේවා, මුලින්ම සිදු වන්නේ Keystone මත ඔබගේ ඉල්ලීමට අවසර දීමයි - ඔබට යන්ත්‍රයක් නිර්මාණය කළ හැකිද, එහි තිබේද? මෙම ජාලය භාවිතා කිරීමට අයිතිය, ඔබේ කෙටුම්පත් කෝටාව, ආදිය.
Keystone производит аутентификацию вашего запроса и генерирует в ответном сообщении auth-токен, который будет использован далее. Получив ответ от Keystone запрос отправляется в сторону Nova (nova api).
Nova-api проверяет валидность вашего запроса, обращаясь в Keystone, используя ранее сгенерированный auth-токен
Keystone සත්‍යාපනය සිදු කරන අතර මෙම සත්‍යාපන ටෝකනය මත පදනම්ව අවසර සහ සීමා කිරීම් පිළිබඳ තොරතුරු සපයයි.
Nova-api создает в nova-database запись о новой VM и передает запрос на создание машины в nova-scheduler.
Nova-scheduler производит выбор хоста (компьют ноды), на которой VM будет развернута на основании заданных параметров, весов и зон. Запись об этом и идентификатор VM записываются в nova-database.
Далее nova-scheduler обращается к nova-compute с запросом об развертывании инстанса. Nova-compute обращается в nova-conductor для получения информации о параметрах машины (nova-conductor является элементом nova, выполняющим роль прокси сервера между nova-database и nova-compute, ограничивая количество запросов в сторону nova-database во избежании проблем с консистентность базы данных сокращения загрузки).
Nova-conductor විසින් ඉල්ලා සිටින තොරතුරු nova-database වෙතින් ලබාගෙන එය nova-compute වෙත ලබා දෙයි.
ඊළඟට, රූප හැඳුනුම්පත ලබා ගැනීමට nova-compute ඇමතුම් බැල්ම. Glace Keystone හි ඉල්ලීම වලංගු කර ඉල්ලා ඇති තොරතුරු ආපසු ලබා දෙයි.
ජාල පරාමිතීන් පිළිබඳ තොරතුරු ලබා ගැනීමට Nova-compute contacts neutron. බැලූ බැල්මට සමානව, නියුට්‍රෝනය Keystone හි ඉල්ලීම වලංගු කරයි, ඉන් පසුව එය දත්ත සමුදායේ ප්‍රවේශයක් නිර්මාණය කරයි (වරාය හඳුනාගැනීම, ආදිය), වරායක් සෑදීමට ඉල්ලීමක් නිර්මාණය කරයි, සහ ඉල්ලා සිටින තොරතුරු nova-compute වෙත ආපසු ලබා දෙයි.
Nova-compute обращается к cinder с запросом выделения виртуальной машине volume. Аналогично glance, cider проводит валидацию запроса в Keystone, создает запрос на создание volume и возвращает запрошенную информацию.
Nova-compute contacts libvirt මගින් නියම කර ඇති පරාමිති සහිත අථත්‍ය යන්ත්‍රයක් යෙදවීමට ඉල්ලීමක් කරයි.

ඇත්ත වශයෙන්ම, සරල අතථ්‍ය යන්ත්‍රයක් නිර්මාණය කිරීමේ සරල මෙහෙයුමක් වලාකුළු වේදිකාවේ මූලද්‍රව්‍ය අතර API ඇමතුම් වල එවැනි සුළි සුළඟක් බවට පත්වේ. එපමණක් නොව, ඔබට පෙනෙන පරිදි, කලින් නම් කරන ලද සේවාවන් පවා අන්තර්ක්‍රියා සිදු වන කුඩා කොටස් වලින් සමන්විත වේ. යන්ත්‍රයක් නිර්මාණය කිරීම වලාකුළු වේදිකාව ඔබට කිරීමට ඉඩ දෙන දෙයින් කුඩා කොටසක් පමණි - ගමනාගමනය සමතුලිත කිරීම සඳහා වගකිව යුතු සේවාවක්, අවහිර ගබඩා කිරීම සඳහා වගකිව යුතු සේවාවක්, DNS සඳහා වගකිව යුතු සේවාවක්, හිස් ලෝහ සේවාදායකයන් සැපයීම සඳහා වගකිව යුතු සේවාවක් යනාදිය ඇත. වලාකුළ ඔබට ඔබගේ අතථ්‍ය යන්ත්‍ර බැටළු රංචුවක් මෙන් සැලකීමට ඉඩ සලසයි (අථත්‍යකරණයට ප්‍රතිවිරුද්ධව). අතථ්‍ය පරිසරයකදී ඔබේ යන්ත්‍රයට යමක් සිදුවුවහොත් - ඔබ එය උපස්ථ ආදියෙන් ප්‍රතිස්ථාපනය කරයි, නමුත් වලාකුළු යෙදුම් ගොඩනඟා ඇත්තේ අතථ්‍ය යන්ත්‍රය එතරම් වැදගත් කාර්යභාරයක් ඉටු නොකරන ආකාරයටය - අථත්‍ය යන්ත්‍රය “මිය ගියේය” - ගැටළුවක් නැත. - නව එකක් නිර්මාණය කර ඇත්තේ වාහනය සැකිල්ල මත පදනම් වූ අතර, ඔවුන් පවසන පරිදි, ප්‍රහාරකයාගේ අලාභය සංචිතයට නොපෙනේ. ස්වාභාවිකවම, මෙය වාද්‍ය වෘන්ද යාන්ත්‍රණ තිබීම සඳහා සපයයි - තාප සැකිලි භාවිතා කිරීමෙන් ඔබට පහසුවෙන් ජාල දුසිම් ගනනක් සහ අථත්‍ය යන්ත්‍ර වලින් සමන්විත සංකීර්ණ කාර්යයක් යෙදවිය හැකිය.

ජාලයක් නොමැතිව වලාකුළු යටිතල ව්‍යුහයක් නොමැති බව සැමවිටම මතක තබා ගැනීම වටී - එක් එක් මූලද්‍රව්‍යය එක් ආකාරයකින් හෝ වෙනත් ආකාරයකින් ජාලය හරහා වෙනත් මූලද්‍රව්‍ය සමඟ අන්තර් ක්‍රියා කරයි. මීට අමතරව, වලාකුළට නිරපේක්ෂ ස්ථිතික නොවන ජාලයක් ඇත. ස්වාභාවිකවම, යටි පෙළ ජාලය ඊටත් වඩා අඩු හෝ අඩු ස්ථිතික වේ - සෑම දිනකම නව නෝඩ් සහ ස්විච එකතු නොකෙරේ, නමුත් ආවරණ සංරචකය නිරන්තරයෙන් වෙනස් විය හැකිය සහ නොවැළැක්විය හැකිය - නව ජාල එකතු කරනු ලැබේ හෝ මකා දැමෙනු ඇත, නව අථත්‍ය යන්ත්‍ර දිස්වනු ඇත, පැරණි ඒවා දිස්වනු ඇත. මැරෙනවා. ලිපියේ ආරම්භයේදීම ලබා දී ඇති වලාකුළේ නිර්වචනයෙන් ඔබට මතක ඇති පරිදි, සම්පත් ස්වයංක්‍රීයව සහ සේවා සපයන්නාගේ අවම වශයෙන් (හෝ වඩා හොඳ, තොරව) මැදිහත්වීමකින් පරිශීලකයාට වෙන් කළ යුතුය. එනම්, දැන් http/https හරහා ප්‍රවේශ විය හැකි ඔබගේ පුද්ගලික ගිණුමේ ඉදිරි අන්තයක ස්වරූපයෙන් පවතින ජාල සම්පත් සැපයීමේ වර්ගය සහ පසුපෙළක් ලෙස රාජකාරියේ යෙදී සිටින ජාල ඉංජිනේරු Vasily වලාකුළක් නොවේ. වාසිලිට අත් අටක් තිබේ නම්.

Neutron, ජාල සේවාවක් ලෙස, Cloud යටිතල ව්‍යුහයේ ජාල කොටස කළමනාකරණය කිරීම සඳහා API සපයයි. Network-as-a-Service (NaaS) නම් වියුක්ත ස්තරයක් ලබා දීමෙන් සේවාව Openstack හි ජාලකරණ කොටස බල ගන්වයි සහ කළමනාකරණය කරයි. එනම්, ජාලය යනු අථත්‍ය මැනිය හැකි ඒකකයයි, උදාහරණයක් ලෙස, අථත්‍ය CPU හරය හෝ RAM ප්‍රමාණය.

නමුත් OpenStack හි ජාල කොටසෙහි ගෘහ නිර්මාණ ශිල්පය වෙත යාමට පෙර, මෙම ජාලය OpenStack හි ක්‍රියා කරන ආකාරය සහ ජාලය වලාකුළෙහි වැදගත් සහ අනිවාර්ය අංගයක් වන්නේ මන්දැයි සලකා බලමු.

ඉතින් අපිට RED client VM දෙකක් සහ GREEN client VM දෙකක් තියෙනවා. මෙම යන්ත්‍ර මේ ආකාරයට හයිපර්වයිසර් දෙකක් මත පිහිටා ඇතැයි උපකල්පනය කරමු:

В данный момент это просто виртуализация 4-х серверов и не более того, так как пока что все что мы сделали — виртуализировали 4 сервера, раположив их на двух физических серверах. Причем пока что они даже не подключены к сети.

වලාකුළක් සෑදීමට, අපි සංරචක කිහිපයක් එකතු කළ යුතුය. පළමුව, අපි ජාල කොටස අථත්යකරණය කරමු - අපි මෙම යන්ත්ර 4 යුගල වශයෙන් සම්බන්ධ කළ යුතු අතර, සේවාලාභීන්ට L2 සම්බන්ධතාවයක් අවශ්ය වේ. ඔබට ස්විචයක් භාවිතා කර එහි දිශාවට කඳක් වින්‍යාස කර ලිනක්ස් පාලමක් භාවිතයෙන් සියල්ල විසඳා ගත හැකිය, නැතහොත් වඩාත් දියුණු පරිශීලකයින් සඳහා openvswitch (අපි මෙය පසුව වෙත ආපසු යමු). නමුත් ජාල විශාල ප්‍රමාණයක් තිබිය හැකි අතර, ස්විචයක් හරහා නිරන්තරයෙන් L2 තල්ලු කිරීම හොඳම අදහස නොවේ - විවිධ දෙපාර්තමේන්තු, සේවා මේසයක්, යෙදුමක් සම්පූර්ණ කිරීමට මාස ගණනක් බලා සිටීම, දෝශ නිරාකරණ සති ඇත - නූතන ලෝකයේ මෙය ප්රවේශය තවදුරටත් ක්රියා නොකරයි. ඒ වගේම සමාගමක් ඉක්මනින්ම මෙය තේරුම් ගන්නවා නම්, එය ඉදිරියට යාම පහසුයි. එබැවින්, හයිපර්වයිසර් අතර අපි අපගේ අථත්‍ය යන්ත්‍ර සන්නිවේදනය කරන L3 ජාලයක් තෝරා ගනිමු, මෙම L3 ජාලයට ඉහළින් අපි අපගේ අථත්‍ය යන්ත්‍රවල ගමනාගමනය ක්‍රියාත්මක වන අථත්‍ය L2 ආවරණ ජාල ගොඩනඟමු. ඔබට GRE, Geneve හෝ VxLAN භාවිතා කළ හැක. එය විශේෂයෙන් වැදගත් නොවූවත්, දැනට දෙවැන්න කෙරෙහි අවධානය යොමු කරමු.

Нам надо где то расположить VTEP (надеюсь все знакомы с терминологией VxLAN). Так как с серверов у нас выходит сразу L3 сеть, то нам ничего не мешает расположить VTEP на самих серверах, причем OVS (OpenvSwitch) это отлично умеет делать. В итоге мы получили вот такую конструкцию:

Так как трафик между VM должен быть разделен, то порты в сторону виртуальных машин будут иметь разные номера вланов. Номер тега играет роль только в пределах одного виртуального коммутатора, так как при инкапсулировании в VxLAN мы его можем беспроблемно снять, так как у нас будет VNI.

Теперь мы можем плодить наши машины и виртуальные сети для них без каких либо проблем.

කෙසේ වෙතත්, සේවාදායකයාට වෙනත් යන්ත්‍රයක් තිබේ නම්, නමුත් වෙනත් ජාලයක සිටී නම් කුමක් කළ යුතුද? අපිට Networks අතර Root කිරීම අවශ්‍යයි. මධ්‍යගත මාර්ගගත කිරීම් භාවිතා කරන විට අපි සරල විකල්පයක් දෙස බලමු - එනම්, ගමනාගමනය විශේෂ කැපවූ ජාල නෝඩ් හරහා යවනු ලැබේ (හොඳයි, රීතියක් ලෙස, ඒවා පාලන නෝඩ් සමඟ සංයුක්ත වේ, එබැවින් අපට එකම දේ ඇත).

එය කිසිවක් සංකීර්ණ නොවන බව පෙනේ - අපි පාලක නෝඩයේ පාලම් අතුරුමුහුණතක් සාදා, එයට ගමනාගමනය ගෙන යන අතර එතැන් සිට එය අපට අවශ්‍ය තැනට යොමු කරමු. නමුත් ගැටළුව වන්නේ RED සේවාදායකයාට 10.0.0.0/24 ජාලය භාවිතා කිරීමට අවශ්‍ය වීම සහ GREEN සේවාදායකයාට 10.0.0.0/24 ජාලය භාවිතා කිරීමට අවශ්‍ය වීමයි. එනම්, අපි ලිපින අවකාශයන් ඡේදනය කිරීමට පටන් ගනිමු. මීට අමතරව, වෙනත් සේවාදායකයින්ට ඔවුන්ගේ අභ්‍යන්තර ජාල වෙත යාමට හැකි වනවාට සේවාදායකයින්ට අවශ්‍ය නැත, එය අර්ථවත් කරයි. ජාල සහ සේවාදායක දත්ත ගමනාගමනය වෙන් කිරීම සඳහා, අපි ඒ සෑම එකක් සඳහාම වෙනම නාම අවකාශයක් වෙන් කරමු. Namespace යනු ඇත්ත වශයෙන්ම Linux ජාල තොගයේ පිටපතකි, එනම්, නාම අවකාශයේ RED හි සේවාලාභීන් ග්‍රීන් නම් අවකාශයෙන් සේවාදායකයින්ගෙන් සම්පූර්ණයෙන්ම හුදකලා වී ඇත (හොඳයි, මෙම සේවාදායක ජාල අතර මාර්ගගත කිරීමට පෙරනිමි නාම අවකාශය හරහා හෝ ඉහළ ප්‍රවාහන උපකරණ මත අවසර දෙනු ලැබේ).

එනම්, අපට පහත රූප සටහන ලැබේ:

L2 උමං මාර්ග සියලුම පරිගණක නෝඩ් වලින් පාලන නෝඩයට අභිසාරී වේ. මෙම ජාල සඳහා L3 අතුරුමුහුණත පිහිටා ඇති node, එක් එක් හුදකලා නාම අවකාශය තුළ.

Однако мы забыли самое главное. Виртуальная машина должна предоставлять сервис клиенту, то есть она должна иметь хотя бы один внешний интерфейс, через который к ней можно достучаться. То есть нам нужно выйти во внешний мир. Тут есть разные варианты. Сделаем самый просто вариант. Добавим клиентам по одной сети, которые будут валидны в сети провайдера и не будут пересекаться с другими сетями. Сети могу быть тоже пересекающимися и смотреть в разные VRF на стороне провайдерской сети. Данные сети также будут жить в namespace каждого из клиентов. Однако выходить во внешний мир они все равно будут через один физический (или бонд, что логичнее) интерфейс. Чтобы разделить трафик клиентов трафик, выходящий наружу будет производиться тегирование VLAN тегом, выделенным клиенту.

ප්රතිඵලයක් වශයෙන්, අපට මෙම රූප සටහන ලැබුණි:

Резонный вопрос — почему не сделать шлюзы на самих compute нодах? Большой проблемы в этом нет, более того, при включении распределенного маршрутизатора (DVR) это так и будет работать. В данном сценарии мы рассматриваем самый простой вариант с централизованным gateway, который в Openstack используется по умолчанию. Для высоконагруженных функций будут использовать как распределенный маршрутизатор, так и технологии ускорения типа SR-IOV и Passthrough, но как говорится, это уже совсем другая история. Для начала разберемся с базовой частью, а потом уйдем в детали.

ඇත්ත වශයෙන්ම, අපගේ යෝජනා ක්රමය දැනටමත් ක්රියාත්මක කළ හැකි නමුත්, සූක්ෂ්මතා කිහිපයක් තිබේ:

Нам надо как то защитить наши машины, то есть повесить на интерфейс свича в сторону клиента фильтр.
අතථ්‍ය යන්ත්‍රයකට ස්වයංක්‍රීයව IP ලිපිනයක් ලබා ගැනීමට හැකි කරවන්න, එවිට ඔබට සෑම විටම කොන්සෝලය හරහා එයට ඇතුළු වී ලිපිනය ලියාපදිංචි කිරීමට අවශ්‍ය නොවේ.

යන්ත්‍ර ආරක්ෂණයෙන් පටන් ගනිමු. මේ සඳහා ඔබට banal iptables භාවිතා කළ හැකිය, ඇයි එසේ නොවේ.

එනම්, දැන් අපගේ ස්ථාන විද්‍යාව ටිකක් සංකීර්ණ වී ඇත:

Пойдем далее. Нам надо добавить DHCP сервер. Самым идеальным местом для расположения DHCP серверов для каждого из клиентов будет уже упомянутая выше контрольная нода, где расположены namespaces:

Однако, есть небольшая проблема. Что если все перезагрузится и вся информация по аренде адресов на DHCP пропадет. Логично, что машинам будут выданы новые адреса, что не очень удобно. Выхода тут два — либо использовать доменные имена и добавить DNS сервер для каждого клиента, тогда нам адрес будет не особо важен (по аналогии с сетевой часть в k8s) — но тут есть проблема с внешними сетями, так как в них адреса также могу быть выданы по DHCP — нужна синхронизация с DNS серверов в облачной платформе и внешним DNS сервером, что на мой взгляд не очень гибко, однако вполне возможно. Либо второй вариант — использовать метаданные — то есть сохранять информацию о выданной машине адресе чтобы DHCP сервер знал, какой адрес машине выдать, если машина уже получала адрес. Второй вариант проще и гибче, так как позволяет сохранить доп информацию о машине. Теперь на схему добавим metadata агента:

සාකච්ඡා කළ යුතු තවත් ගැටළුවක් වන්නේ සියලුම සේවාදායකයින් විසින් එක් බාහිර ජාලයක් භාවිතා කිරීමේ හැකියාවයි, මන්ද බාහිර ජාල, ඒවා මුළු ජාලය පුරාම වලංගු විය යුතු නම්, දුෂ්කර වනු ඇත - ඔබ මෙම ජාල වෙන් කිරීම නිරන්තරයෙන් වෙන් කර පාලනය කළ යුතුය. පොදු වලාකුළක් නිර්මාණය කිරීමේදී සියලුම සේවාලාභීන් සඳහා තනි බාහිර පෙර-වින්‍යාසගත ජාලයක් භාවිතා කිරීමේ හැකියාව ඉතා ප්‍රයෝජනවත් වනු ඇත. ලිපින දත්ත සමුදායක් පරිශීලනය කිරීමට සහ එක් එක් සේවාදායකයාගේ බාහිර ජාලය සඳහා අනන්‍ය ලිපින ඉඩක් තෝරා ගැනීමට අවශ්‍ය නොවන නිසා මෙය යන්ත්‍ර යෙදවීම පහසු කරනු ඇත. ඊට අමතරව, අපට බාහිර ජාලයක් කල්තියා ලියාපදිංචි කළ හැකි අතර, යෙදවීමේදී අපට අවශ්‍ය වන්නේ සේවාදායක යන්ත්‍ර සමඟ බාහිර ලිපින සම්බන්ධ කිරීම පමණි.

තවද මෙහිදී NAT අපගේ ආධාරයට පැමිණේ - NAT පරිවර්තනය භාවිතයෙන් පෙරනිමි නාම අවකාශය හරහා ගනුදෙනුකරුවන්ට බාහිර ලෝකයට ප්‍රවේශ වීමට අපි ඉඩ සලසන්නෙමු. හොඳයි, මෙන්න පොඩි ගැටලුවක්. සේවාදායක සේවාදායකය සේවාදායකයක් ලෙස නොව සේවාදායකයෙකු ලෙස ක්‍රියා කරන්නේ නම් මෙය හොඳයි - එනම්, එය සම්බන්ධතා පිළිගන්නවාට වඩා ආරම්භ කරයි. නමුත් අපට එය අනෙක් පැත්ත වනු ඇත. මෙම අවස්ථාවේදී, අපි ගමනාන්තය NAT කළ යුතු අතර එමඟින් ගමනාගමනය ලැබෙන විට, පාලක නෝඩය තේරුම් ගනී මෙම ගමනාගමනය A ග්‍රාහක A හි අථත්‍ය යන්ත්‍රය සඳහා වන බව, එයින් අදහස් කරන්නේ අපට බාහිර ලිපිනයකින් NAT පරිවර්තනයක් කළ යුතු බවයි, උදාහරණයක් ලෙස 100.1.1.1. .10.0.0.1, අභ්‍යන්තර ලිපිනයකට 100. මෙම අවස්ථාවෙහිදී, සියලුම සේවාදායකයින් එකම ජාලය භාවිතා කරනු ඇතත්, අභ්යන්තර හුදකලාව සම්පූර්ණයෙන්ම සංරක්ෂණය කර ඇත. එනම්, අපි පාලන නෝඩයේ dNAT සහ sNAT කළ යුතුය. පාවෙන ලිපින හෝ බාහිර ජාල සහිත තනි ජාලයක් භාවිතා කරන්නේද, නැතහොත් දෙකම එකවර භාවිතා කරන්නේද යන්න, ඔබට වලාකුළට ගෙන ඒමට අවශ්‍ය දේ මත රඳා පවතී. අපි රූප සටහනට පාවෙන ලිපින එකතු නොකරමු, නමුත් කලින් එකතු කර ඇති බාහිර ජාල අත්හරිමු - සෑම සේවාදායකයෙකුටම තමන්ගේම බාහිර ජාලයක් ඇත (රූප සටහනේ ඒවා බාහිර අතුරු මුහුණතේ vlan 200 සහ XNUMX ලෙස දක්වා ඇත).

В итоге мы получили интересное и в то же время продуманное решение, обладающее определенной гибкость но пока что не обладающее механизмами отказоустойчивости.

Во первых у нас всего одна контрольная нода — выход ее из строя приведет к краху все системы. Для устранения данной проблемы необходимо сделать как минимум кворум из 3-х нод. Добавим это на схему:

Естественно все ноды синхронизируются и при выходе активной ноды ее обязанности на себя возьмет другая нода.

ඊළඟ ගැටළුව වන්නේ අථත්ය යන්ත්ර තැටි වේ. මේ මොහොතේ, ඒවා හයිපර්වයිසර්වලම ගබඩා කර ඇති අතර, හයිපර්වයිසර් සමඟ ඇති ගැටළු වලදී, අපට සියලු දත්ත අහිමි වේ - සහ අපට තැටිය නොව සමස්ත සේවාදායකයම නැති වුවහොත් වැටලීමක් තිබීම මෙහි උපකාරී නොවේ. මෙය සිදු කිරීම සඳහා, අපි යම් ආකාරයක ගබඩාවක් සඳහා ඉදිරිපස කෙළවර ලෙස ක්රියා කරන සේවාවක් සෑදිය යුතුය. එය කුමන ආකාරයේ ගබඩාවක් වනු ඇත්ද යන්න අපට විශේෂයෙන් වැදගත් නොවේ, නමුත් එය අපගේ දත්ත තැටියේ සහ නෝඩයේ අසාර්ථක වීමෙන් සහ සමහර විට මුළු කැබිනට් මණ්ඩලයම ආරක්ෂා කළ යුතුය. මෙහි විකල්ප කිහිපයක් තිබේ - ඇත්ත වශයෙන්ම, ෆයිබර් නාලිකාව සමඟ SAN ජාල ඇත, නමුත් අපි අවංක වෙමු - FC දැනටමත් අතීතයේ ධාතුවකි - ප්‍රවාහනයේදී E1 හි ප්‍රතිසමයක් - ඔව්, මම එකඟ වෙමි, එය තවමත් භාවිතා වේ, නමුත් එය නොමැතිව එය සම්පූර්ණයෙන්ම කළ නොහැකි තැන පමණි. එබැවින්, තවත් රසවත් විකල්ප ඇති බව දැන, මම 2020 දී ස්වේච්ඡාවෙන් FC ජාලයක් යොදවන්නේ නැත. සෑම කෙනෙකුටම තමන්ගේම වුවද, FC එහි සියලු සීමාවන් සමඟ අපට අවශ්‍ය වන්නේ යැයි විශ්වාස කරන අය සිටිය හැකිය - මම තර්ක නොකරමි, සෑම කෙනෙකුටම තමන්ගේම මතයක් ඇත. කෙසේ වෙතත්, මගේ මතය අනුව වඩාත්ම සිත්ගන්නා විසඳුම වන්නේ Ceph වැනි SDS භාවිතා කිරීමයි.

Ceph позволяет построить выскодоступное решение для хранения данных с кучей возможных вариантов резервирования, начиная с кодов с проверкой четности (аналог рейд 5 или 6) заканчивая полной репликацией данных на разные диски с учетом расположения дисков в серверах, и серверов в шкафах и т д.

Для сборки Ceph нужно еще 3 ноды. Взаимодействие с хранилищем будет производиться также через сеть с использованием служб блочного, объектного и файлового хранилищ. Добавим в схему хранилище:

සටහන: ඔබට හයිපර්කොන්වර්ඩ් පරිගණක නෝඩ් සෑදිය හැකිය - මෙය එක් නෝඩයක ශ්‍රිත කිහිපයක් ඒකාබද්ධ කිරීමේ සංකල්පයයි - උදාහරණයක් ලෙස, ගබඩාව + ගණනය කිරීම - ceph ගබඩා කිරීම සඳහා විශේෂ නෝඩ් කැප නොකර. අප විසින් නියම කරන ලද වෙන් කිරීමේ මට්ටම සමඟ SDS දත්ත වෙන් කර ගන්නා බැවින් - අපට එකම දෝෂ-ඉවසන යෝජනා ක්‍රමයක් ලැබෙනු ඇත. කෙසේ වෙතත්, අධිසන්ධි නෝඩ් සෑම විටම සම්මුතියකි - ගබඩා නෝඩය බැලූ බැල්මට පෙනෙන පරිදි වාතය රත් නොකරන බැවින් (එහි අතථ්‍ය යන්ත්‍ර නොමැති බැවින්) - එය SDS සේවා සඳහා CPU සම්පත් වැය කරයි (ඇත්ත වශයෙන්ම, එය සියල්ල කරයි. නෝඩ්, තැටි ආදිය අසාර්ථක වීමෙන් පසු අනුකරණය සහ යථා තත්ත්වයට පත් කිරීම). එනම්, ඔබ එය ගබඩා කිරීම සමඟ ඒකාබද්ධ කළහොත්, පරිගණක නෝඩයේ බලයෙන් කොටසක් ඔබට අහිමි වනු ඇත.

මේ සියල්ල කෙසේ හෝ කළමනාකරණය කළ යුතුය - අපට යන්ත්‍රයක්, ජාලයක්, අතථ්‍ය රවුටරයක් ආදිය සෑදිය හැකි යමක් අවශ්‍ය වේ. මෙය සිදු කිරීම සඳහා, අපි පාලක නෝඩයට උපකරණ පුවරුවක් ලෙස ක්‍රියා කරන සේවාවක් එක් කරන්නෙමු - සේවාදායකයාට http/ https හරහා මෙම ද්වාරයට සම්බන්ධ වීමට සහ ඔහුට අවශ්‍ය සියල්ල (හොඳින්, පාහේ) කිරීමට හැකි වනු ඇත.

В итоге теперь мы имеем отказоустойчивую систему. Всеми элементами данной инфраструктуры надо как то управлять. Ранее было описано, что Openstack — это набор проектов, каждый их которых обеспечивает какую то определенную функцию. Как мы видим элементов, которые надо конфигурировать и контролировать более чем достаточно. Сегодня мы поговорим о сетевой части.

නියුට්‍රෝන ගෘහ නිර්මාණ ශිල්පය

OpenStack හි, සාමාන්‍ය L2 ජාලයකට අතථ්‍ය යන්ත්‍ර තොටුපළ සම්බන්ධ කිරීම, විවිධ L2 ජාලවල පිහිටා ඇති VM අතර ගමනාගමන මාර්ගගත කිරීම සහතික කිරීම මෙන්ම බාහිර මාර්ගගත කිරීම, NAT, Floating IP, DHCP වැනි සේවාවන් සැපයීම සඳහා වගකිව යුත්තේ Neutron ය.

Высокоуровнево работу сетевой службы (базовая часть) можно описать так.

VM ආරම්භ කරන විට, ජාල සේවාව:

Создает порт для данной VM (или порты) и оповещает об этом DHCP сервис;
නව අතථ්‍ය ජාල උපාංගයක් සාදනු ලැබේ (libvirt හරහා);
VM 1 පියවරේදී නිර්මාණය කරන ලද වරාය(s) වෙත සම්බන්ධ කරයි;

Как ни странно, но в основе работы Neutron лежат стандартные механизмы, знакомые всем, что когда либо погружался в Linux — это namespaces, iptables, linux bridges, openvswitch, conntrack и т д.

Следует сразу уточнить, что Neutron не является SDN контроллером.

නියුට්‍රෝන අන්තර් සම්බන්ධිත සංරචක කිහිපයකින් සමන්විත වේ:

Openstack-neutron-server — это демон, который через API работает с пользовательскими запросами. Данный демон не занимается прописыванием каких либо сетевых связностей, а дает необходимую для этого информацию своим плагинам, которые далее настраивают нужный элемент сети. Neutron-агенты на узлах OpenStack регистрируются на сервере Neutron.

නියුට්‍රෝන-සේවාදායකය ඇත්ත වශයෙන්ම කොටස් දෙකකින් සමන්විත python වලින් ලියා ඇති යෙදුමකි:

REST සේවාව
Neutron Plugin (core/service)

REST සේවාව වෙනත් සංරචක වලින් API ඇමතුම් ලබා ගැනීමට සැලසුම් කර ඇත (උදාහරණයක් ලෙස, යම් තොරතුරු සැපයීමට ඉල්ලීමක්, ආදිය)

Plugins යනු API ඉල්ලීම් අතරතුර කැඳවනු ලබන ප්ලග්-ඉන් මෘදුකාංග සංරචක/මොඩියුල - එනම්, සේවාවක ආරෝපණය ඒවා හරහා සිදුවේ. ප්ලගීන වර්ග දෙකකට බෙදා ඇත - සේවා සහ මූල. රීතියක් ලෙස, අශ්ව ප්ලගිනය VM අතර ලිපින අවකාශය සහ L2 සම්බන්ධතා කළමනාකරණය කිරීම සඳහා ප්‍රධාන වශයෙන් වගකිව යුතු අතර සේවා ප්ලගීන දැනටමත් VPN හෝ FW වැනි අමතර ක්‍රියාකාරීත්වයක් සපයයි.

Список доступных на сегодня плагинов можно посмотреть например මෙහි

සේවා ප්ලගින කිහිපයක් තිබිය හැක, නමුත් තිබිය හැක්කේ එක් අශ්ව ප්ලගිනයක් පමණි.

openstack-neutron-ml2 සම්මත Openstack root ප්ලගිනය වේ. මෙම ප්ලගිනයට මොඩියුලර් ගෘහ නිර්මාණ ශිල්පයක් ඇත (එහි පූර්වගාමියා මෙන් නොව) සහ එයට සම්බන්ධ ධාවක හරහා ජාල සේවාව වින්‍යාස කරයි. ඇත්ත වශයෙන්ම එය OpenStack ජාල කොටසෙහි ඇති නම්‍යශීලී බව ලබා දෙන බැවින් අපි ප්ලගිනය මඳ වේලාවකට පසුව බලමු. මූල ප්ලගිනය ප්‍රතිස්ථාපනය කළ හැකිය (උදාහරණයක් ලෙස, Contrail Networking එවැනි ආදේශනයක් කරයි).

RPC සේවාව (rabbitmq-server) — сервис, обеспечивающий управлением очередями и взаимодействие с другими службами OpenStack а также взаимодействие между агентами сетевой службы.

ජාල නියෝජිතයන් - ජාල සේවා වින්‍යාස කර ඇති එක් එක් නෝඩය තුළ පිහිටා ඇති නියෝජිතයන්.

Агенты бывают нескольких видов.

Основной агент — это L2 නියෝජිතයා. මෙම නියෝජිතයන් පාලන නෝඩ් (වඩාත් නිවැරදිව, කුලී නිවැසියන් සඳහා ඕනෑම සේවාවක් සපයන සියලුම නෝඩ් මත) ඇතුළුව එක් එක් අධි වයිසර් මත ක්‍රියාත්මක වන අතර ඔවුන්ගේ ප්‍රධාන කාර්යය වන්නේ සාමාන්‍ය L2 ජාලයකට අතථ්‍ය යන්ත්‍ර සම්බන්ධ කිරීම සහ කිසියම් සිදුවීමක් සිදු වූ විට ඇඟවීම් ජනනය කිරීමයි ( උදාහරණයක් ලෙස වරාය අක්‍රිය/සක්‍රීය කරන්න).

ඊළඟට, අඩු වැදගත් නියෝජිතයා නොවේ L3 නියෝජිතයා. පෙරනිමියෙන්, මෙම නියෝජිතයා තනිකරම ජාල නෝඩයක් මත ක්‍රියා කරයි (බොහෝ විට ජාල නෝඩය පාලන නෝඩයක් සමඟ සංයුක්ත වේ) සහ කුලී නිවැසියන්ගේ ජාල (එහි ජාල සහ අනෙකුත් කුලී නිවැසියන්ගේ ජාල අතර, සහ බාහිර ලෝකයට ප්‍රවේශ විය හැකි අතර, මාර්ගගත කිරීම සපයයි. NAT, මෙන්ම DHCP සේවාව). කෙසේ වෙතත්, DVR (බෙදා හරින ලද රවුටරය) භාවිතා කරන විට, L3 ප්ලගිනයක අවශ්‍යතාවය පරිගණක නෝඩ් වල ද දිස්වේ.

L3 නියෝජිතයා සෑම කුලී නිවැසියෙකුටම තමන්ගේම හුදකලා ජාල කට්ටලයක් සහ ගමනාගමනය මෙහෙයවන සහ Layer 2 ජාල සඳහා ද්වාර සේවා සපයන අතථ්‍ය රවුටරවල ක්‍රියාකාරීත්වය සැපයීමට Linux නාම අවකාශයන් භාවිතා කරයි.

දත්ත සමුදාය - ජාල, උපජාල, වරාය, තටාක ආදිය හඳුනාගැනීමේ දත්ත ගබඩාවක්.

ඇත්ත වශයෙන්ම, Neutron විසින් ඕනෑම ජාල ආයතන සෑදීමේදී API ඉල්ලීම් පිළිගනී, ඉල්ලීම සත්‍යාපනය කරයි, සහ RPC (එය යම් ප්ලගිනයක් හෝ නියෝජිතයෙකු වෙත ප්‍රවේශ වන්නේ නම්) හෝ REST API (එය SDN හි සන්නිවේදනය කරන්නේ නම්) නියෝජිතයන් වෙත සම්ප්‍රේෂණය කරයි (ප්ලගින හරහා) ඉල්ලා සිටින සේවාව සංවිධානය කිරීමට අවශ්ය උපදෙස්.

දැන් අපි පරීක්ෂණ ස්ථාපනය වෙත හැරෙමු (එය යොදවා ඇති ආකාරය සහ එයට ඇතුළත් කර ඇති දේ, අපි පසුව ප්‍රායෝගික කොටසින් බලමු) සහ එක් එක් සංරචක පිහිටා ඇත්තේ කොතැනදැයි බලමු:

(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host                                | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent           | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-l3-agent          |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent         | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-dhcp-agent        |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent     | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$

ඇත්ත වශයෙන්ම, එය නියුට්‍රෝනයේ සම්පූර්ණ ව්‍යුහයයි. දැන් එය ML2 ප්ලගිනය මත යම් කාලයක් ගත කිරීම වටී.

මොඩියුලර් ස්ථරය 2

ඉහත සඳහන් කළ පරිදි, ප්ලගිනය සම්මත OpenStack root ප්ලගිනයක් වන අතර මොඩියුලර් ගෘහ නිර්මාණ ශිල්පයක් ඇත.

ML2 ප්ලගිනයේ පූර්වගාමියාට මොනොලිතික් ව්‍යුහයක් තිබුණි, එය එක් ස්ථාපනයකදී තාක්ෂණයන් කිහිපයක මිශ්‍රණයක් භාවිතා කිරීමට ඉඩ නොදේ. උදාහරණයක් ලෙස, ඔබට openvswitch සහ linuxbridge යන දෙකම එකවර භාවිතා කළ නොහැක - පළමු හෝ දෙවන. මෙම හේතුව නිසා, එහි ගෘහ නිර්මාණ ශිල්පය සමඟ ML2 ප්ලගිනය නිර්මාණය කරන ලදී.

ML2 හි සංරචක දෙකක් ඇත - ධාවක වර්ග දෙකක්: ධාවක වර්ග සහ යාන්ත්‍රික ධාවක.

ධාවක වර්ග ජාල සම්බන්ධතා සංවිධානය කිරීමට භාවිතා කරන තාක්ෂණයන් තීරණය කරන්න, උදාහරණයක් ලෙස VxLAN, VLAN, GRE. ඒ සමගම, ධාවකය විවිධ තාක්ෂණයන් භාවිතා කිරීමට ඉඩ සලසයි. සම්මත තාක්ෂණය වන්නේ අතිච්ඡාදනය වන ජාල සහ vlan බාහිර ජාල සඳහා VxLAN encapsulation වේ.

ධාවක වර්ග වලට පහත ජාල වර්ග ඇතුළත් වේ:

පැතලි - ටැග් කිරීමකින් තොරව ජාලය
VLANs - ටැග් කළ ජාලය
දේශීය — специальный тип сети для инсталляций типа all-in-one (такие инсталляции нужны либо для разработчиков либо для обучения)
GRE — overlay сеть, использующая GRE тоннели
VxLAN - VxLAN උමං භාවිතා කරමින් උඩැතිරි ජාලය

යාන්ත්රික ධාවකයන් ධාවක වර්ගයෙහි දක්වා ඇති තාක්ෂණයන් සංවිධානය කිරීම සහතික කරන මෙවලම් නිර්වචනය කරන්න - උදාහරණයක් ලෙස, openvswitch, sr-iov, opendaylight, OVN, ආදිය.

В зависимости от реализации данного драйвера будет использованы либо агенты, которые управляются Neutron, либо использоваться соединения с внешним SDN контроллером, который берет на себя все вопросы по организации L2 сетей, маршрутизации и т д.

Пример если мы используем ML2 вместе с OVS, то на каждой вычислительной ноде устанавливается L2 агент, который управляет OVS. Однако если мы используем например OVN или OpenDayLight, то управление OVS переходит под их юрисдикцию — Neutron через корневой плагин дает команды контроллеру, а он уже делает то, что ему сказали.

අපි Open vSwitch මත මදින්න

මේ මොහොතේ, OpenStack හි එක් ප්‍රධාන අංගයක් වන්නේ Open vSwitch ය.
Juniper Contrail හෝ Nokia Nuage වැනි අමතර වෙළෙන්දා SDN නොමැතිව OpenStack ස්ථාපනය කරන විට, OVS යනු Cloud ජාලයේ ප්‍රධාන ජාල සංරචකය වන අතර, iptables, conntrack, namespaces සමඟින්, ඔබට සම්පූර්ණ බහු-කුලී ආවරණ ජාල සංවිධානය කිරීමට ඉඩ සලසයි. ස්වාභාවිකවම, මෙම සංරචකය ප්රතිස්ථාපනය කළ හැකිය, උදාහරණයක් ලෙස, තෙවන පාර්ශවීය හිමිකාර (වෙළෙන්දා) SDN විසඳුම් භාවිතා කරන විට.

OVS යනු අථත්‍ය ගමනාගමන යොමු කරන්නෙකු ලෙස අථත්‍යකරණය කළ පරිසරයන්හි භාවිතය සඳහා නිර්මාණය කර ඇති විවෘත මූලාශ්‍ර මෘදුකාංග ස්විචයකි.

මේ මොහොතේ, OVS සතුව QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK වැනි තාක්ෂණයන් ඇතුළත් ඉතා යහපත් ක්‍රියාකාරීත්වයක් ඇත.

සටහන: OVS මුලින් සංකල්පනය කරනු ලැබුවේ අධික ලෙස පටවන ලද ටෙලිකොම් ක්‍රියාකාරකම් සඳහා මෘදු ස්විචයක් ලෙස නොවන අතර WEB සේවාදායකය හෝ තැපැල් සේවාදායකය වැනි අඩු කලාප පළලක් ඉල්ලුමක් ඇති තොරතුරු තාක්ෂණ කාර්යයන් සඳහා වඩාත් නිර්මාණය කර ඇත. කෙසේ වෙතත්, OVS තවදුරටත් සංවර්ධනය වෙමින් පවතින අතර OVS හි වත්මන් ක්‍රියාත්මක කිරීම් එහි ක්‍රියාකාරීත්වය සහ හැකියාවන් බෙහෙවින් වැඩි දියුණු කර ඇති අතර, එය අධික ලෙස පටවන ලද කාර්යයන් සහිත ටෙලිකොම් ක්‍රියාකරුවන්ට භාවිතා කිරීමට ඉඩ සලසයි, උදාහරණයක් ලෙස, DPDK ත්වරණය සඳහා සහය ඇති OVS ක්‍රියාත්මක කිරීමක් ඇත.

ඔබ දැනුවත් විය යුතු OVS හි වැදගත් කොටස් තුනක් තිබේ:

කර්නල් මොඩියුලය - පාලන මූලද්රව්යයෙන් ලැබුණු නීති මත පදනම්ව රථවාහන සකසන කර්නල් අවකාශයේ පිහිටා ඇති සංරචකයකි;
vSwitch daemon (ovs-vswitchd) යනු කර්නල් මොඩියුලය ක්‍රමලේඛනය කිරීම සඳහා වගකිව යුතු පරිශීලක අවකාශයේ දියත් කරන ලද ක්‍රියාවලියකි - එනම්, එය ස්විචයේ ක්‍රියාකාරිත්වයේ තර්කනය කෙලින්ම නියෝජනය කරයි.
දත්ත සමුදා සේවාදායකය - වින්‍යාසය ගබඩා කර ඇති OVS ධාවනය වන එක් එක් සත්කාරකයේ පිහිටා ඇති දේශීය දත්ත සමුදායක්. SDN පාලකයන්ට OVSDB ප්‍රොටෝකෝලය භාවිතයෙන් මෙම මොඩියුලය හරහා සන්නිවේදනය කළ හැක.

මේ සියල්ල සමඟ ovs-vsctl, ovs-appctl, ovs-ofctl, වැනි රෝග විනිශ්චය සහ කළමනාකරණ උපයෝගිතා කට්ටලයක් ඇත.

දැනට, Openstack EPC, SBC, HLR වැනි ජාල ක්‍රියාකාරකම් වෙත සංක්‍රමණය කිරීමට ටෙලිකොම් ක්‍රියාකරුවන් විසින් බහුලව භාවිතා කරයි. සමහර කාර්යයන් OVS සමඟ ගැටළු නොමැතිව ජීවත් විය හැක, නමුත් උදාහරණයක් ලෙස, EPC ග්‍රාහක තදබදය ක්‍රියාවට නංවයි - එවිට එය හරහා ගමන් කරයි. විශාල තදබදයක් (දැන් රථවාහන පරිමාව තත්පරයට ගිගාබිට් සිය ගණනකට ළඟා වේ). ස්වාභාවිකවම, කර්නල් අවකාශය හරහා එවැනි ගමනාගමනය ධාවනය කිරීම (ඉදිරිපත් කරන්නා පෙරනිමියෙන් එහි පිහිටා ඇති බැවින්) හොඳම අදහස නොවේ. එබැවින්, OVS බොහෝ විට DPDK ත්වරණය තාක්ෂණය භාවිතයෙන් NIC සිට පරිශීලක අවකාශය වෙත කර්නලය මඟහරිමින් ගමනාගමනය යොමු කිරීම සඳහා සම්පූර්ණයෙන්ම පරිශීලක අවකාශයේ යොදවනු ලැබේ.

සටහන: ටෙලිකොම් ක්‍රියාකාරකම් සඳහා යොදවා ඇති වලාකුළක් සඳහා, පරිගණක නෝඩයකින් ගමනාගමනය ප්‍රතිදානය කිරීමට OVS සෘජුවම මාරු කිරීමේ උපකරණ වෙත ගමන් කළ හැකිය. මේ සඳහා SR-IOV සහ Passthrough යාන්ත්‍රණ භාවිතා වේ.

මෙය සැබෑ පිරිසැලසුමක ක්‍රියා කරන්නේ කෙසේද?

හොඳයි, දැන් අපි ප්‍රායෝගික කොටස වෙත ගොස් එය ප්‍රායෝගිකව ක්‍රියාත්මක වන්නේ කෙසේදැයි බලමු.

Для начала развернем простенькую Openstack инсталляцию. Так как у меня под рукой под эксперименты нет набора серверов, то собирать макет будем на одном физическом сервере из виртуальных машин. Да, естественно под коммерческие цели такое решение не подходит, но чтобы посмотреть на примере как работает сеть в Openstack такой инсталляции хватит за глаза. Причем такая инсталляция для целей обучения даже интереснее — так как можно отловить трафик и т д.

අපට දැකීමට අවශ්‍ය වන්නේ මූලික කොටස පමණක් බැවින්, අපට ජාල කිහිපයක් භාවිතා කළ නොහැකි නමුත් ජාල දෙකක් පමණක් භාවිතයෙන් සියල්ල ඉහළ දැමිය හැකි අතර, මෙම පිරිසැලසුමේ ඇති දෙවන ජාලය undercloud සහ DNS සේවාදායකයට ප්‍රවේශ වීම සඳහා පමණක් භාවිතා වේ. අපි දැනට බාහිර ජාල ස්පර්ශ නොකරමු - මෙය වෙනම විශාල ලිපියක් සඳහා මාතෘකාවකි.

Итак, начнем по порядку. Сначала немного теории. Ставить мы будем Openstack с помощью TripleO (Openstack on Openstack). Суть TripleO заключается в том, что мы устанавливаем Openstack all-in-one (то есть на одну ноду), называемый undercloud, и далее используем возможности развернутого Openstack чтобы установить Openstack, предназначенный для эксплуатации, называемый overcloud. Undercloud будет использовать заложенную в него возможность управлять физическими серверами (bare metal) — проект Ironic — для провижининга гипервизоров, которые будут выполнять роли compute, control, storage нод. То есть мы не используем никаких сторонних средств для развертывания Openstack — мы разворачиваем Openstack силами Openstack. Далее по ходу установки станет намного понятнее, поэтому не будем останавливать на этом и пойдем вперед.

සටහන: මෙම ලිපියේ, සරල බව සඳහා, මම අභ්‍යන්තර Openstack ජාල සඳහා ජාල හුදකලා කිරීම භාවිතා නොකළ නමුත් සෑම දෙයක්ම එක් ජාලයක් පමණක් භාවිතා කර ඇත. කෙසේ වෙතත්, ජාල හුදකලා වීම හෝ නොපැවතීම විසඳුමේ මූලික ක්‍රියාකාරීත්වයට බලපාන්නේ නැත - හුදකලා කිරීම භාවිතා කරන විට සෑම දෙයක්ම හරියටම ක්‍රියා කරනු ඇත, නමුත් ගමනාගමනය එකම ජාලයක් මත ගලා යයි. වාණිජමය ස්ථාපනයක් සඳහා, විවිධ vlans සහ අතුරුමුහුණත් භාවිතයෙන් හුදකලා කිරීම ස්වභාවිකවම අවශ්‍ය වේ. උදාහරණයක් ලෙස, ceph ගබඩා කළමනාකරණ ගමනාගමනය සහ දත්ත ගමනාගමනය (තැටි වෙත යන්ත්‍ර ප්‍රවේශය, ආදිය) හුදකලා වූ විට විවිධ උපජාල (ගබඩා කළමනාකරණය සහ ආචයනය) භාවිතා කරන අතර මෙය ඔබට මෙම ගමනාගමනය බෙදීමෙන් විසඳුම වඩාත් දෝෂ-ප්‍රතිරෝධී කිරීමට ඉඩ සලසයි. , විවිධ වරායන් හරහා, හෝ විවිධ ගමනාගමනය සඳහා විවිධ QoS පැතිකඩ භාවිතා කරමින් දත්ත ගමනාගමනය සංඥා ගමනාගමනය මිරිකන්නේ නැත. අපගේ නඩුවේදී, ඔවුන් එකම ජාලයකට යන අතර ඇත්ත වශයෙන්ම මෙය අපව කිසිඳු ආකාරයකින් සීමා නොකරයි.

සටහන: අපි අතථ්‍ය යන්ත්‍ර මත පදනම් වූ අතථ්‍ය පරිසරයක් තුළ අථත්‍ය යන්ත්‍ර ධාවනය කිරීමට යන බැවින්, අපි පළමුව කැදැලි අථත්‍යකරණය සක්‍රීය කළ යුතුය.

Проверить, включена ли nested виртуализация или нет можно так:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested
N
[root@hp-gen9 bormoglotx]# 
Если вы видите букву N, то включаем поддержку nested виртуализации по любому гайду, который найдете в сети, например එවැනි .

අථත්‍ය යන්ත්‍ර වලින් අපි පහත පරිපථය එකලස් කළ යුතුය:

මගේ නඩුවේදී, අනාගත ස්ථාපනයේ කොටසක් වන අථත්‍ය යන්ත්‍ර සම්බන්ධ කිරීම සඳහා (සහ මට ඒවායින් 7 ක් ලැබුණි, නමුත් ඔබට බොහෝ සම්පත් නොමැති නම් ඔබට 4 සමඟ ලබා ගත හැකිය), මම OpenvSwitch භාවිතා කළෙමි. මම එක් ovs පාලමක් නිර්මාණය කර port-groups හරහා එයට අතථ්‍ය යන්ත්‍ර සම්බන්ධ කළෙමි. මෙය සිදු කිරීම සඳහා, මම මෙවැනි xml ගොනුවක් සෑදුවෙමි:


[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1        
<network>
  <name>ovs-network-1</name>
  <uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
  <forward mode='bridge'/>
  <bridge name='ovs-br1'/>
  <virtualport type='openvswitch'/>
  <portgroup name='trunk-1'>
    <vlan trunk='yes'>
      <tag id='100'/>
      <tag id='101'/>
      <tag id='102'/>
    </vlan>
  </portgroup>
  <portgroup name='access-100'>
    <vlan>
      <tag id='100'/>
    </vlan>
  </portgroup>
  <portgroup name='access-101'>
    <vlan>
      <tag id='101'/>
    </vlan>
  </portgroup>
</network>

Тут объявлены три порт группы — две access и одна trunk (последняя нужна была для DNS сервера, но можно обойтись и без него, либо поднять его на хостовой машине — это как вам удобнее). Далее с помощью данного шаблона объявляем нашу есть через virsh net-define:


virsh net-define ovs-network-1.xml 
virsh net-start ovs-network-1 
virsh net-autostart ovs-network-1

දැන් අපි හයිපර්වයිසර් වරාය වින්‍යාසයන් සංස්කරණය කරන්නෙමු:


[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0   
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1 
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]#

Примечание: в данном сценарии адрес на порту ovs-br1 не будет доступен, так как он не имеет влан тега. Чтобы это поправить надо дать команду sudo ovs-vsctl set port ovs-br1 tag=100. Однако после перезагрузки данный тег пропадет (если кто знает как заставить его остаться на месте — буду очень благодарен). Но это не столь важно, ибо данный адрес нам понадобится только на время инсталляции и будет не нужен, когда Openstack будет полностью развернут.

ඊළඟට, අපි undercloud යන්ත්රයක් නිර්මාණය කරමු:


virt-install  -n undercloud --description "undercloud"  --os-type=Linux  --os-variant=centos7.0  --ram=8192  --vcpus=8  --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none  --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0

ස්ථාපනය අතරතුර, ඔබ යන්ත්‍ර නාමය, මුරපද, පරිශීලකයින්, ntp සේවාදායකයන් වැනි අවශ්‍ය සියලු පරාමිතීන් සකසා ඇත, ඔබට වහාම වරායන් වින්‍යාසගත කළ හැකිය, නමුත් මට පුද්ගලිකව, ස්ථාපනය කිරීමෙන් පසු, යන්ත්‍රයට ලොග් වීම පහසුය. කොන්සෝලය සහ අවශ්ය ගොනු නිවැරදි කරන්න. ඔබට දැනටමත් සූදානම් කළ රූපයක් තිබේ නම්, ඔබට එය භාවිතා කළ හැකිය, නැතහොත් මා කළ දේ කරන්න - අවම Centos 7 රූපය බාගත කර VM ස්ථාපනය කිරීමට එය භාවිතා කරන්න.

සාර්ථක ස්ථාපනයකින් පසුව, ඔබට undercloud ස්ථාපනය කළ හැකි අතථ්‍ය යන්ත්‍රයක් තිබිය යුතුය


[root@hp-gen9 bormoglotx]# virsh list
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 62    undercloud                     running

Сначала ставим необходимые в процессе установки инструменты:

sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool

යට වලාකුළු ස්ථාපනය

අපි ස්ටැක් පරිශීලකයෙකු සාදා, මුරපදයක් සකසා, එය sudoer වෙත එක් කර මුරපදයක් ඇතුළත් නොකර sudo හරහා root විධාන ක්‍රියාත්මක කිරීමේ හැකියාව ඔහුට ලබා දෙමු:


useradd stack
passwd stack

echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stack

දැන් අපි ධාරක ගොනුවේ සම්පූර්ණ යටි වලාකුළු නම සඳහන් කරමු:


vi /etc/hosts

127.0.0.1   undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

ඊළඟට, අපි ගබඩා එකතු කර අපට අවශ්‍ය මෘදුකාංග ස්ථාපනය කරමු:


sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansible

Примечание: если вы не планируете ставить ceph, то команды, относящиеся к ceph вводить не надо. Я использовал релиз Queens, но вы можете использовать любой другой, который вам понравится.

ඊළඟට, යටි වලාකුළු වින්‍යාස ගොනුව පරිශීලකයාගේ මුල් නාමාවලි තොගයට පිටපත් කරන්න:


cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf

දැන් අපි මෙම ගොනුව නිවැරදි කළ යුතු අතර, එය අපගේ ස්ථාපනය වෙත සකස් කරන්න.

ඔබ ගොනුවේ ආරම්භයට මෙම රේඛා එක් කළ යුතුය:

vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10

Итак, пройдем по настройкам:

undercloud_hostname — undercloud සේවාදායකයේ සම්පූර්ණ නම, DNS සේවාදායකයේ ඇතුළත් කිරීම සමඟ ගැලපිය යුතුය

local_ip — локальный адрес undercloud в сторону провиженинг сети

network_gateway — overcloud nodes ස්ථාපනය කිරීමේදී බාහිර ලෝකයට ප්‍රවේශය සඳහා දොරටුවක් ලෙස ක්‍රියා කරන එම ප්‍රාදේශීය ලිපිනයම දේශීය ip සමඟ සමපාත වේ.

undercloud_public_host - බාහිර API ලිපිනය, ප්‍රතිපාදන ජාලයෙන් ඕනෑම නොමිලේ ලිපිනයක් පවරනු ලැබේ

undercloud_admin_host адрес внутреннего API, назначается любой свободный адрес из провижининг сети

undercloud_nameservers - DNS සේවාදායකය

උත්පාදනය_සේවා_සහතිකය — данная строка очень важна в текущем примере, так как если ее не установить в значение false вы получите ошибку при установке, проблема описана на багтрекер Red Hat

දේශීය_අතුරුමුහුණත ජාල ප්‍රතිපාදන වල අතුරු මුහුණත. මෙම අතුරුමුහුණත යටි වලාකුළු යෙදවීමේදී නැවත වින්‍යාස කරනු ඇත, එබැවින් ඔබට undercloud මත අතුරුමුහුණත් දෙකක් තිබිය යුතුය - එකක් එයට ප්‍රවේශ වීම සඳහා, දෙවැන්න ප්‍රතිපාදන සඳහා

දේශීය_mtu - MTU. අප සතුව පරීක්ෂණ රසායනාගාරයක් ඇති නිසාත් OVS ස්විච් පෝට් වල MTU 1500ක් ඇති නිසාත් VxLAN වලින් කොටු කර ඇති පැකට් වලට ගමන් කිරීමට හැකි වන පරිදි එය 1450 ලෙස සැකසීමට අවශ්‍ය වේ.

network_cidr - ප්රතිපාදන ජාලය

වෙස් මුහුණු - බාහිර ජාලයකට පිවිසීමට NAT භාවිතා කිරීම

වෙස් මුහුණු_ජාලය - NATed කරනු ලබන ජාලය

dhcp_start - අධි ක්ලවුඩ් යෙදවීමේදී නෝඩ් වෙත ලිපින පවරනු ලබන ලිපින සංචිතයේ ආරම්භක ලිපිනය

dhcp_end - අධි ක්ලවුඩ් යෙදවීමේදී නෝඩ් වෙත ලිපින පවරනු ලබන ලිපින සංචිතයේ අවසාන ලිපිනය

පරීක්ෂන_ඉප්රේන්ජ් — пул адресов, необходимых для проведения интроспекции (не должен пересекаться с вышеобозначенным пулом)

කාලසටහන්_උපරිම_උත්සාහයන් - overcloud ස්ථාපනය කිරීමට උපරිම උත්සාහයන් ගණන (නෝඩ් ගණනට වඩා වැඩි හෝ සමාන විය යුතුය)

ගොනුව විස්තර කළ පසු, ඔබට undercloud යෙදවීමට විධානය ලබා දිය හැකිය:


openstack undercloud install

ක්රියා පටිපාටිය ඔබේ යකඩ මත පදනම්ව විනාඩි 10 සිට 30 දක්වා ගත වේ. අවසානයේ ඔබට මෙවැනි ප්‍රතිදානයක් දැකිය යුතුය:

vi undercloud.conf
2020-08-13 23:13:12,668 INFO: 
#############################################################################
Undercloud install complete.

The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.

There is also a stackrc file at /home/stack/stackrc.

These files are needed to interact with the OpenStack services, and should be
secured.

#############################################################################

මෙම ප්‍රතිදානය පවසන්නේ ඔබ සාර්ථකව undercloud ස්ථාපනය කර ඇති බවත් ඔබට දැන් undercloud තත්ත්වය පරීක්ෂා කර overcloud ස්ථාපනය කිරීමට ඉදිරියට යා හැකි බවත්ය.

ඔබ ifconfig ප්‍රතිදානය දෙස බැලුවහොත්, නව පාලම් අතුරුමුහුණතක් පැමිණ ඇති බව ඔබට පෙනෙනු ඇත

[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.1  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe2c:89e  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:2c:08:9e  txqueuelen 1000  (Ethernet)
        RX packets 14  bytes 1095 (1.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 20  bytes 1292 (1.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

අධි ක්ලවුඩ් යෙදවීම දැන් මෙම අතුරු මුහුණත හරහා සිදු කෙරේ.

පහත ප්‍රතිදානයෙන් ඔබට පෙනෙනුයේ අප සියලු සේවාවන් එක් නෝඩයක ඇති බව ය:

(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name                | Service   | Zone     |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute   | nova     |
+--------------------------+-----------+----------+

පහත දැක්වෙන්නේ undercloud ජාල කොටසෙහි වින්‍යාසය:


(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json 
{
    "network_config": [
        {
            "addresses": [
                {
                    "ip_netmask": "192.168.255.1/24"
                }
            ],
            "members": [
                {
                    "dns_servers": [
                        "192.168.255.253"
                    ],
                    "mtu": 1450,
                    "name": "eth0",
                    "primary": "true",
                    "type": "interface"
                }
            ],
            "mtu": 1450,
            "name": "br-ctlplane",
            "ovs_extra": [
                "br-set-external-id br-ctlplane bridge-id br-ctlplane"
            ],
            "routes": [],
            "type": "ovs_bridge"
        }
    ]
}
(undercloud) [stack@undercloud ~]$

අධි ක්ලවුඩ් ස්ථාපනය

මේ මොහොතේ අප සතුව ඇත්තේ යටි වලාකුළක් පමණක් වන අතර, අධික වලාකුළු එකලස් කරන ප්‍රමාණවත් නෝඩ් අප සතුව නොමැත. එමනිසා, පළමුවෙන්ම, අපට අවශ්‍ය අථත්‍ය යන්ත්‍ර යොදවමු. යෙදවීමේදී, undercloud විසින්ම OS සහ අවශ්‍ය මෘදුකාංග ඕවර් ක්ලවුඩ් යන්ත්‍රයේ ස්ථාපනය කරනු ඇත - එනම්, අපට යන්ත්‍රය සම්පූර්ණයෙන්ම යෙදවීමට අවශ්‍ය නැත, නමුත් ඒ සඳහා තැටියක් (හෝ තැටි) නිර්මාණය කර එහි පරාමිතීන් තීරණය කරන්න - එනම්. , ඇත්ත වශයෙන්ම, අපට OS ස්ථාපනය කර නොමැති හිස් සේවාදායකයක් ලැබේ.

අපි අපේ අතථ්‍ය යන්ත්‍රවල තැටි සහිත ෆෝල්ඩරය වෙත ගොස් අවශ්‍ය ප්‍රමාණයේ තැටි සාදන්න:


cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160G

Так как действуем мы от рута, то нам надо изменить владельца этих дисков чтобы не получить проблему с правами:


[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root  61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root  61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root  61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]# 
[root@hp-gen9 images]# 
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]#

සටහන: ඔබ එය අධ්‍යයනය කිරීම සඳහා ceph ස්ථාපනය කිරීමට අදහස් නොකරන්නේ නම්, විධාන අවම වශයෙන් තැටි දෙකක් සහිත නෝඩ් 3 ක් වත් නිර්මාණය නොකරයි, නමුත් අච්චුවේ දැක්වෙන්නේ අථත්‍ය තැටි vda, vdb යනාදිය භාවිතා කරන බවයි.

Отлично, теперь нам надо все эти машины определить:


virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > /tmp/control-1.xml  

virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-1.xml  

virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-2.xml  

virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-1.xml  

virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-2.xml

В конце есть команды —print-xml > /tmp/storage-1.xml, которая создает xml файл с описанием каждой машине в папке /tmp/, если ее не добавить, то не сможете определить виртуальные машины.

දැන් අපි මේ සියලුම යන්ත්‍ර virsh වලින් නිර්වචනය කළ යුතුයි:


virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml

[root@hp-gen9 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 -     compute-1                      shut off
 -     compute-2                      shut off
 -     control-1                      shut off
 -     storage-1                      shut off
 -     storage-2                      shut off

[root@hp-gen9 ~]#

දැන් කුඩා සූක්ෂ්මතාවයක් - ත්‍රිත්ව ඕ IPMI භාවිතා කරමින් ස්ථාපනය සහ අභ්‍යන්තර පරීක්‍ෂණය අතරතුර සේවාදායකයන් කළමනාකරණය කරයි.

Интроспекция — это процесс инспекции аппратной части в целях получения ее параметров, необходимых для дальнешего провижининга нод. Интроспекция производится с помошью ironic — службы, предназначенной для работы с bare metal серверами.

නමුත් මෙන්න ගැටලුව - දෘඪාංග IPMI සේවාදායකයන්ට වෙනම වරායක් (හෝ හවුල් වරායක් ඇත, නමුත් මෙය වැදගත් නොවේ), අථත්‍ය යන්ත්‍රවලට එවැනි වරායන් නොමැත. මෙන්න vbmc නම් කිහිලිකරු අපගේ ආධාරයට පැමිණේ - ඔබට IPMI වරායක් අනුකරණය කිරීමට ඉඩ සලසන උපයෝගීතාවයකි. ESXI හයිපර්වයිසර් මත එවැනි රසායනාගාරයක් සැකසීමට කැමති අය සඳහා මෙම සූක්ෂ්මතාවය විශේෂයෙන් අවධානය යොමු කිරීම වටී - අවංකව කිවහොත්, එයට vbmc හි ප්‍රතිසමයක් තිබේදැයි මම නොදනිමි, එබැවින් සියල්ල යෙදවීමට පෙර මෙම ගැටළුව ගැන කල්පනා කිරීම වටී. .

vbmc ස්ථාපනය කරන්න:


yum install yum install python2-virtualbmc

Если ваша ОС не может найти пакет, то добавьте репозиторий:

yum install -y https://www.rdoproject.org/repos/rdo-release.rpm

දැන් අපි උපයෝගීතාව සකස් කරමු. මෙහි ඇති සෑම දෙයක්ම අපකීර්තියට පත්වන තරමට අශෝභන ය. දැන් vbmc ලැයිස්තුවේ සේවාදායකයක් නොමැති බව තර්කානුකූලයි


[root@hp-gen9 ~]# vbmc list

[root@hp-gen9 ~]#

ඒවා දිස්වීමට නම්, ඒවා අතින් ප්‍රකාශ කළ යුත්තේ මෙසේය.


[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1   | down   | ::      | 7004 |
| compute-2   | down   | ::      | 7005 |
| control-1   | down   | ::      | 7001 |
| storage-1   | down   | ::      | 7002 |
| storage-2   | down   | ::      | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#

Думаю синтаксис команды понятен и без объяснений. Однако пока что все наши сессии в статусе DOWN. Чтобы они перешли в статус UP, необходимо их включить:


[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1 
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status  | Address | Port |
+-------------+---------+---------+------+
| compute-1   | running | ::      | 7004 |
| compute-2   | running | ::      | 7005 |
| control-1   | running | ::      | 7001 |
| storage-1   | running | ::      | 7002 |
| storage-2   | running | ::      | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#

අවසාන ස්පර්ශය - ඔබ ෆයර්වෝල් නීති නිවැරදි කළ යුතුය (නැතහොත් එය සම්පූර්ණයෙන්ම අක්‍රීය කරන්න):


firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload

දැන් අපි undercloud වෙත ගොස් සියල්ල ක්‍රියාත්මක වේද යන්න පරීක්ෂා කරමු. ධාරක යන්ත්‍රයේ ලිපිනය 192.168.255.200 වේ, අපි යෙදවීම සඳහා සූදානම් වීමේදී අවශ්‍ය ipmitool පැකේජය යටි වලාකුළු මත එකතු කළෙමු:


[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status          
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list 
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 65    control-1                      running

ඔබට පෙනෙන පරිදි, අපි vbmc හරහා පාලන නෝඩය සාර්ථකව දියත් කර ඇත. දැන් අපි එය ක්‍රියා විරහිත කර ඉදිරියට යමු:


[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 -     compute-1                      shut off
 -     compute-2                      shut off
 -     control-1                      shut off
 -     storage-1                      shut off
 -     storage-2                      shut off

[root@hp-gen9 ~]#

මීලඟ පියවර වන්නේ අධි වලාකුළු ස්ථාපනය කරන නෝඩ් පිළිබඳ ස්වයං පරීක්ෂණයයි. මෙය සිදු කිරීම සඳහා, අපි අපගේ නෝඩ් පිළිබඳ විස්තරයක් සහිත json ගොනුවක් සකස් කළ යුතුය. හිස් සේවාදායකයන් මත ස්ථාපනය මෙන් නොව, ගොනුව එක් එක් යන්ත්‍රය සඳහා vbmc ක්‍රියාත්මක වන වරාය පෙන්නුම් කරන බව කරුණාවෙන් සලකන්න.


[root@hp-gen9 ~]# virsh domiflist --domain control-1 
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:20:a2:2f
-          network    ovs-network-1 virtio      52:54:00:3f:87:9f

[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:98:e9:d6

[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:6a:ea:be

[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:79:0b:cb

[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:a7:fe:27

Примечание: на контрольной ноде два интерфейса, но в данном случае это не важно, в данной инсталляции нам хватит и одного.

දැන් අපි json ගොනුව සකස් කරමු. ප්‍රතිපාදන සිදු කරනු ලබන වරායේ පොපි ලිපිනය, නෝඩ් වල පරාමිතීන්, ඒවාට නම් ලබා දී ipmi වෙත යන්නේ කෙසේදැයි සඳහන් කළ යුතුය:


{
    "nodes":[
        {
            "mac":[
                "52:54:00:20:a2:2f"
            ],
            "cpu":"8",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"control-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7001"
        },
        {
            "mac":[
                "52:54:00:79:0b:cb"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7002"
        },
        {
            "mac":[
                "52:54:00:a7:fe:27"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7003"
        },
        {
            "mac":[
                "52:54:00:98:e9:d6"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7004"
        },
        {
            "mac":[
                "52:54:00:6a:ea:be"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7005"
        }
    ]
}

දැන් අපි උත්ප්රාසය සඳහා රූප සකස් කළ යුතුයි. මෙය සිදු කිරීම සඳහා, ඒවා wget හරහා බාගත කර ස්ථාපනය කරන්න:

(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack  916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack  15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/                       
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$ 
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack  53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$

underCloud වෙත පින්තූර උඩුගත කිරීම:

(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
|                  ID                  |          Name          | Disk Format |   Size  | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz |     aki     | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
|                  ID                  |          Name         | Disk Format |   Size   | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd |     ari     | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
|                  ID                  |      Name      | Disk Format |    Size    | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full |    qcow2    | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
|                  ID                  |       Name       | Disk Format |   Size  | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel |     aki     | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
|                  ID                  |        Name       | Disk Format |    Size   | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk |     ari     | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$

Проверяем, что все образы загрузились


(undercloud) [stack@undercloud ~]$  openstack image list
+--------------------------------------+------------------------+--------+
| ID                                   | Name                   | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel       | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk      | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full         | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd  | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$

තවත් එක් දෙයක් - ඔබ DNS සේවාදායකයක් එක් කළ යුතුය:


(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID                                   | Name            | Network                              | Subnet           |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field             | Value                                                     |
+-------------------+-----------------------------------------------------------+
| allocation_pools  | 192.168.255.11-192.168.255.50                             |
| cidr              | 192.168.255.0/24                                          |
| created_at        | 2020-08-13T20:10:37Z                                      |
| description       |                                                           |
| dns_nameservers   |                                                           |
| enable_dhcp       | True                                                      |
| gateway_ip        | 192.168.255.1                                             |
| host_routes       | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id                | f45dea46-4066-42aa-a3c4-6f84b8120cab                      |
| ip_version        | 4                                                         |
| ipv6_address_mode | None                                                      |
| ipv6_ra_mode      | None                                                      |
| name              | ctlplane-subnet                                           |
| network_id        | 6ca013dc-41c2-42d8-9d69-542afad53392                      |
| prefix_length     | None                                                      |
| project_id        | a844ccfcdb2745b198dde3e1b28c40a3                          |
| revision_number   | 0                                                         |
| segment_id        | None                                                      |
| service_types     |                                                           |
| subnetpool_id     | None                                                      |
| tags              |                                                           |
| updated_at        | 2020-08-13T20:10:37Z                                      |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$ 
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253                                    
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$

දැන් අපට ස්වයං විමර්ශනය සඳහා විධානය ලබා දිය හැකිය:

(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json 
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.


5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$

නිමැවුමෙන් ඔබට පෙනෙන පරිදි, සෑම දෙයක්ම දෝෂයකින් තොරව සම්පූර්ණ කර ඇත. සියලුම නෝඩ් පවතින තත්වයේ තිබේදැයි පරීක්ෂා කරමු:


(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID                                 | Name      | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None          | power off   | available          | False       |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None          | power off   | available          | False       |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None          | power off   | available          | False       |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None          | power off   | available          | False       |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None          | power off   | available          | False       |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$

නෝඩ් වෙනත් තත්වයක තිබේ නම්, සාමාන්‍යයෙන් කළමනාකරණය කළ හැකි නම්, යමක් වැරදී ඇති අතර, ඔබ ලොගය දෙස බලා මෙය සිදු වූයේ මන්දැයි සොයා බැලිය යුතුය. මෙම අවස්ථාවෙහිදී අපි අථත්‍යකරණය භාවිතා කරන අතර අතථ්‍ය යන්ත්‍ර හෝ vbmc භාවිතය හා සම්බන්ධ දෝෂ තිබිය හැකි බව මතක තබා ගන්න.

මීලඟට, අපි කුමන කාර්යය ඉටු කරන්නේද යන්න සඳහන් කළ යුතුය - එනම්, නෝඩය යෙදවිය යුතු පැතිකඩ සඳහන් කරන්න:


(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available       | None            |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available       | None            |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available       | None            |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available       | None            |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available       | None            |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID                                   | Name          |  RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 |   40 |         0 |     1 | True      |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal     | 4096 |   40 |         0 |     1 | True      |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control       | 4096 |   40 |         0 |     1 | True      |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 |   40 |         0 |     1 | True      |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute       | 4096 |   40 |         0 |     1 | True      |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage  | 4096 |   40 |         0 |     1 | True      |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$

එක් එක් නෝඩය සඳහා පැතිකඩ සඳහන් කරන්න:


openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167

අපි සෑම දෙයක්ම නිවැරදිව කළාදැයි පරීක්ෂා කර බලමු:


(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available       | control         |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available       | ceph-storage    |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available       | ceph-storage    |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available       | compute         |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available       | compute         |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$

සියල්ල නිවැරදි නම්, අපි overcloud යෙදවීමට විධානය ලබා දෙමු:

openstack overcloud deploy --templates --control-scale 1 --compute-scale 2  --ceph-storage-scale 2 --control-flavor control --compute-flavor compute  --ceph-storage-flavor ceph-storage --libvirt-type qemu

В реальной инсталляции естественно будут использовать кастомизированные темплейты, в нашем случае это очень сильно усложнит процесс, так как надо будет объяснить каждую правку в шаблоне. Как было написано ранее — даже простой инсталляции нам будет достаточно, чтобы посмотреть, как это работает.

සටහන: මෙම අවස්ථාවෙහිදී --libvirt-type qemu විචල්‍යය අවශ්‍ය වේ, මන්ද අපි nested virtualization භාවිතා කරමු. එසේ නොමැතිනම්, ඔබට අතථ්‍ය යන්ත්‍ර ක්‍රියාත්මක කිරීමට නොහැකි වනු ඇත.

දැන් ඔබට පැයක් පමණ ඇත, හෝ සමහර විට (දෘඪාංගයේ හැකියාවන් මත පදනම්ව) සහ ඔබට බලාපොරොත්තු විය හැක්කේ මෙම කාලයෙන් පසු ඔබ පහත සඳහන් සෙල්ලිපිය දකිනු ඇත:


2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE  Stack CREATE completed successfully

 Stack overcloud CREATE_COMPLETE 

Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$

Теперь у вас есть почти полноценная версия опенстак, на которой вы можете учиться, ставить опыты и т д.

සෑම දෙයක්ම නිවැරදිව ක්‍රියාත්මක වන බව පරීක්ෂා කර බලමු. පරිශීලකයාගේ මුල් නාමාවලියේ ගොනු දෙකක් ඇත - එකක් stackrc (undercloud කළමනාකරණය සඳහා) සහ දෙවන overcloudrc (overcloud කළමනාකරණය සඳහා). මෙම ගොනු සත්‍යාපනය සඳහා අවශ්‍ය තොරතුරු අඩංගු බැවින් ඒවා මූලාශ්‍රය ලෙස සඳහන් කළ යුතුය.


(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID                                   | Name                    | Status | Networks                | Image          | Flavor       |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0  | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control      |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute      |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute      |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$


(undercloud) [stack@undercloud ~]$ source overcloudrc 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID                               | Name    |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin   |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host                                | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent           | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-l3-agent          |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent         | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-dhcp-agent        |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent     | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$

මගේ ස්ථාපනය සඳහා තවමත් එක් කුඩා ස්පර්ශයක් අවශ්‍ය වේ - මා වැඩ කරන යන්ත්‍රය වෙනත් ජාලයක ඇති බැවින් පාලකය මත මාර්ගයක් එක් කිරීම. මෙය සිදු කිරීම සඳහා, තාප පරිපාලක ගිණුම යටතේ පාලනය-1 වෙත ගොස් මාර්ගය ලියාපදිංචි කරන්න


(undercloud) [stack@undercloud ~]$ ssh [email protected]         
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254

Ну и теперь вы можете зайти в горизонт. Вся информация — адреса, логин и пароль — лежат в файле /home/stack/overcloudrc. Итоговая схема выглядит следующим образом:

К слову говоря, в нашей инсталляции адреса машин выдавались через DHCP и как видите, они выдаются “как попало”. Вы можете в темплейте жестко задать, какой адрес какой машине нужно прикрепить во время деплоя, если вам это необходимо.

අතථ්‍ය යන්ත්‍ර අතර ගමනාගමනය ගලා යන්නේ කෙසේද?

මෙම ලිපියෙන් අපි රථවාහන ගමන් කිරීම සඳහා විකල්ප තුනක් දෙස බලමු

Две машины на одном гипервизоре в одной L2 сети
එකම L2 ජාලයේ විවිධ හයිපර්වයිසර් මත යන්ත්‍ර දෙකක්
විවිධ ජාල වල යන්ත්‍ර දෙකක් (හරස් ජාල මුල්බැසීම)

බාහිර ජාලයක් හරහා බාහිර ලෝකයට ප්‍රවේශය ඇති අවස්ථා, පාවෙන ලිපින භාවිතා කිරීම මෙන්ම බෙදා හරින ලද මාර්ගගත කිරීම්, අපි ඊළඟ වතාවේ සලකා බලමු, දැනට අපි අභ්‍යන්තර ගමනාගමනය කෙරෙහි අවධානය යොමු කරමු.

පරීක්ෂා කිරීම සඳහා, අපි පහත රූප සටහන සකස් කරමු:

අපි අතථ්‍ය යන්ත්‍ර 4ක් නිර්මාණය කර ඇත - එක් L3 ජාලයක 2ක් - net-1, සහ තවත් 1 නෙට්-2 ජාලයේ

(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c             
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID                                   | Name | Tenant ID                        | Status | Task State | Power State | Networks        |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-2=10.0.2.8  |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$

සාදන ලද යන්ත්‍ර පිහිටා ඇත්තේ කුමන හයිපර්වයිසර් මතදැයි බලමු:

(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-1                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000001                                        |

(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-2                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000002                                        |

(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-3                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000003                                        |

(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-4                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000004                                        |

(අධි වලාකුළු) [stack@undercloud ~]$
යන්ත්‍ර vm-1 සහ vm-3 ගණක-0 හි ද, යන්ත්‍ර vm-2 සහ vm-4 නෝඩ් පරිගණනය-1 හි ද පිහිටා ඇත.

Кроме того создан виртуальный маршрутизатор для возможности маршрутизации между указанными сетями:

(overcloud) [stack@undercloud ~]$ openstack router list  --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID                                   | Name     | Status | State | Distributed | HA    | Project                          |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP    | False       | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$

У маршрутизатора два виртуальных порта, который выполняют роль шлюзов для сетей:

(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info         | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$

නමුත් රථවාහන ගලා යන ආකාරය බැලීමට පෙර, අපි දැනට පාලන නෝඩයේ (එයද ජාල නෝඩයකි) සහ පරිගණක නෝඩයේ ඇති දේ බලමු. අපි පරිගණක නෝඩයෙන් පටන් ගනිමු.


[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
  br-ex:
    br-ex 65534/1: (internal)
    phy-br-ex 1/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/2: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
  br-tun:
    br-tun 65534/3: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

මේ මොහොතේ, නෝඩයේ ovs පාලම් තුනක් ඇත - br-int, br-tun, br-ex. ඔවුන් අතර, අප දකින පරිදි, අතුරු මුහුණත් කට්ටලයක් ඇත. තේරුම් ගැනීමේ පහසුව සඳහා, මෙම සියලු අතුරුමුහුණත් රූප සටහනේ සටහන් කර කුමක් සිදුවේදැයි බලමු.

VxLAN උමං එසවී ඇති ලිපිනයන් දෙස බලන විට, එක් උමගක් ගණනය කිරීම-1 (192.168.255.26) සඳහා ඉහළ නංවා ඇති බව පෙනේ, දෙවන උමග පාලනය-1 (192.168.255.15) දෙස බලයි. නමුත් වඩාත්ම සිත්ගන්නා කරුණ නම් br-ex හි භෞතික අතුරුමුහුණත් නොමැති අතර, ප්‍රවාහයන් වින්‍යාස කර ඇති දේ දෙස බැලුවහොත්, මෙම පාලමට මේ මොහොතේ ගමනාගමනය අඩු කළ හැක්කේ පමණක් බව ඔබට පෙනෙනු ඇත.


[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.19  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe6a:eabe  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:6a:ea:be  txqueuelen 1000  (Ethernet)
        RX packets 2909669  bytes 4608201000 (4.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1821057  bytes 349198520 (333.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-novacompute-0 ~]$

ප්‍රතිදානයෙන් ඔබට පෙනෙන පරිදි, ලිපිනය කෙලින්ම ඉස්කුරුප්පු කර ඇත්තේ භෞතික වරායට මිස අතථ්‍ය පාලම් අතුරුමුහුණතට නොවේ.


[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-ofctl dump-flows br-ex
 cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
 cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$

පළමු රීතියට අනුව, phy-br-ex වරායෙන් පැමිණි සියල්ල ඉවත දැමිය යුතුය.
Собственно в данный бридж пока что больше неоткуда взяться трафику, кроме как из данного интерфейса (стык с br-int), и судя по дропам в бридж уже прилетал BUM трафик.

එනම්, ගමනාගමනයට මෙම නෝඩයෙන් පිටවිය හැක්කේ VxLAN උමග හරහා පමණක් වන අතර අන් කිසිවක් නොවේ. කෙසේ වෙතත්, ඔබ DVR ක්‍රියාත්මක කළහොත්, තත්වය වෙනස් වනු ඇත, නමුත් අපි එය වෙනත් අවස්ථාවක ගනුදෙනු කරන්නෙමු. ජාල හුදකලා කිරීම භාවිතා කරන විට, උදාහරණයක් ලෙස vlans භාවිතා කරන විට, ඔබට vlan 3 හි එක් L0 අතුරුමුහුණතක් නොව අතුරුමුහුණත් කිහිපයක් ඇත. කෙසේ වෙතත්, VxLAN ගමනාගමනය ඒ ආකාරයෙන්ම නෝඩයෙන් පිටව යනු ඇත, නමුත් යම් ආකාරයක කැපවූ vlan එකකින් ද සංවෘත වේ.

අපි පරිගණක නෝඩය වර්ග කර ඇත, අපි පාලන නෝඩය වෙත යමු.


[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
  br-ex:
    br-ex 65534/1: (internal)
    eth0 1/2: (system)
    phy-br-ex 2/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/3: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
  br-tun:
    br-tun 65534/4: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$

По факту можно сказать, что все тоже самое, однако ip адрес уже находится не на физическом интерфейсе а на виртуальном бридже. Это сделано из-за того, что данный порт является портом, через который будет выходить трафик во внешний мир.


[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.15  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe20:a22f  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:20:a2:2f  txqueuelen 1000  (Ethernet)
        RX packets 803859  bytes 1732616116 (1.6 GiB)
        RX errors 0  dropped 63  overruns 0  frame 0
        TX packets 808475  bytes 121652156 (116.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
    3   100  28:c0:da:00:4d:d3   35
    1     0  28:c0:da:00:4d:d3   35
    1     0  52:54:00:98:e9:d6    0
LOCAL     0  52:54:00:20:a2:2f    0
    1     0  52:54:00:2c:08:9e    0
    3   100  52:54:00:20:a2:2f    0
    1     0  52:54:00:6a:ea:be    0
[heat-admin@overcloud-controller-0 ~]$

මෙම වරාය br-ex පාලමට සම්බන්ධ කර ඇති අතර එහි vlan ටැග් නොමැති බැවින්, මෙම වරාය සියලුම vlans වලට අවසර ඇති කඳ වරායකි, දැන් ටැග් එකක් නොමැතිව ගමනාගමනය පිටතට යයි, එහි vlan-id 0 මගින් පෙන්වා ඇත. ඉහත ප්රතිදානය.

Все остальное в данный момент аналогично compute ноде — те же бриджи, те же тоннели, идущие на две compute ноды.

අපි මෙම ලිපියේ ගබඩා නෝඩ් සලකා බලන්නේ නැත, නමුත් අවබෝධ කර ගැනීම සඳහා මෙම නෝඩ් වල ජාල කොටස අපකීර්තියට පත්වන බව පැවසිය යුතුය. අපගේ නඩුවේදී, IP ලිපිනයක් ලබා දී ඇත්තේ එක් භෞතික වරායක් (eth0) පමණක් වන අතර එය එයයි. VxLAN උමං, උමං පාලම් යනාදිය නොමැත - එහි කිසිදු තේරුමක් නොමැති බැවින් ovs කිසිසේත් නැත. ජාල හුදකලා කිරීම භාවිතා කරන විට, මෙම නෝඩයට අතුරුමුහුණත් දෙකක් ඇත (භෞතික වරායන්, බොඩ්නි හෝ vlans දෙකක් - එය කමක් නැත - එය ඔබට අවශ්‍ය දේ මත රඳා පවතී) - එකක් කළමනාකරණය සඳහා, දෙවැන්න ගමනාගමනය සඳහා (VM තැටියට ලිවීම) , තැටියෙන් කියවීම ආදිය)

කිසිදු සේවාවක් නොමැති විට නෝඩ් වල ඇති දේ අපි සොයා ගත්තෙමු. දැන් අපි අතථ්‍ය යන්ත්‍ර 4 ක් දියත් කර ඉහත විස්තර කර ඇති යෝජනා ක්‍රමය වෙනස් වන ආකාරය බලමු - අපට වරායන්, අථත්‍ය රවුටර ආදිය තිබිය යුතුය.

Пока что наша сеть выглядит вот так:

У нас по две виртуальные машины на каждой компьют ноде. На примере compute-0 посмотрим, как все включено.


[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list 
 Id    Name                           State
----------------------------------------------------
 1     instance-00000001              running
 3     instance-00000003              running

[heat-admin@overcloud-novacompute-0 ~]$

У машины всего один виртуальный интерфейс — tap95d96a75-a0:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$

මෙම අතුරු මුහුණත ලිනක්ස් පාලමෙහි දිස්වේ:

[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.0242904c92a8       no
qbr5bd37136-47          8000.5e4e05841423       no              qvb5bd37136-47
                                                        tap5bd37136-47
qbr95d96a75-a0          8000.de076cb850f6       no              qvb95d96a75-a0
                                                        tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$

ප්‍රතිදානයෙන් ඔබට පෙනෙන පරිදි, පාලමේ ඇත්තේ අතුරු මුහුණත් දෙකක් පමණි - tap95d96a75-a0 සහ qvb95d96a75-a0.

OpenStack හි ඇති අතථ්‍ය ජාල උපාංග වර්ග පිළිබඳව ටිකක් වාසය කිරීම වටී:
vtap - අථත්‍ය අතුරුමුහුණත නිදසුනකට (VM) අමුණා ඇත
qbr — Linux bridge
qvb и qvo — vEth пара, подключенная к Linux bridge и Open vSwitch bridge
br-int, br-tun, br-vlan - විවෘත vSwitch පාලම්
patch-, int-br-, phy-br- — Open vSwitch patch-интерфейсы, соединяющие bridges
qg, qr, ha, fg, sg - OVS වෙත සම්බන්ධ වීමට අතථ්‍ය උපාංග භාවිතා කරන vSwitch වරායන් විවෘත කරන්න

ඔබ තේරුම් ගත් පරිදි, අපට පාලමේ qvb95d96a75-a0 වරායක් තිබේ නම්, එය vEth යුගලයක් නම්, එහි කොතැනක හෝ එහි සහකරු ඇත, එය තාර්කිකව qvo95d96a75-a0 ලෙස හැඳින්විය යුතුය. OVS හි ඇති වරායන් මොනවාදැයි බලමු.


[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
  br-ex:
    br-ex 65534/1: (internal)
    phy-br-ex 1/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/2: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
    qvo5bd37136-47 6/6: (system)
    qvo95d96a75-a0 3/5: (system)
  br-tun:
    br-tun 65534/3: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

අපට පෙනෙන පරිදි, වරාය br-int හි ඇත. Br-int අතථ්‍ය යන්ත්‍ර වරායන් අවසන් කරන ස්විචයක් ලෙස ක්‍රියා කරයි. qvo95d96a75-a0 ට අමතරව, ප්‍රතිදානයේ qvo5bd37136-47 වරාය දෘශ්‍යමාන වේ. මෙය දෙවන අතථ්‍ය යන්ත්‍රයට වරායයි. එහි ප්රතිඵලයක් වශයෙන්, අපගේ රූප සටහන දැන් මේ ආකාරයෙන් පෙනේ:

අවධානයෙන් සිටින පාඨකයාට වහාම උනන්දු විය යුතු ප්රශ්නයක් - අතථ්‍ය යන්ත්‍ර වරාය සහ OVS වරාය අතර ලිනක්ස් පාලම කුමක්ද? කාරණය නම් යන්ත්‍රය ආරක්ෂා කිරීම සඳහා ආරක්ෂක කණ්ඩායම් භාවිතා කරන අතර ඒවා iptables වලට වඩා වැඩි දෙයක් නොවේ. OVS iptables සමඟ ක්‍රියා නොකරයි, එබැවින් මෙම “කිහිලිකරු” සොයා ගන්නා ලදී. කෙසේ වෙතත්, එය යල්පැනෙමින් පවතී - එය නව නිකුතු වල කොන්ට්‍රැක් මගින් ප්‍රතිස්ථාපනය වේ.

එනම්, අවසානයේ යෝජනා ක්රමය මේ ආකාරයෙන් පෙනේ:

Две машины на одном гипервизоре в одной L2 сети

මෙම VM දෙක එකම L2 ජාලයක සහ එකම හයිපර්වයිසරයක පිහිටා ඇති බැවින්, යන්ත්‍ර දෙකම එකම VLAN මත පවතින බැවින්, ඒවා අතර ගමනාගමනය br-int හරහා දේශීයව ගලා යයි:


[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap5bd37136-47 bridge     qbr5bd37136-47 virtio      fa:16:3e:83:ad:a4

[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int 
 port  VLAN  MAC                Age
    6     1  fa:16:3e:83:ad:a4    0
    3     1  fa:16:3e:44:98:20    0
[heat-admin@overcloud-novacompute-0 ~]$

එකම L2 ජාලයේ විවිධ හයිපර්වයිසර් මත යන්ත්‍ර දෙකක්

Теперь посмотрим, как пойдет трафик между двумя машинами в одной L2 сети, но расположенными на разных гипервизорах. Если быть честным, то особо сильно ничего не поменяется, просто трафик между гипервизорами пойдет через vxlan тоннель. Посмотрим на примере.

අපි ගමනාගමනය නරඹන අතථ්‍ය යන්ත්‍රවල ලිපින:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$


[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tape7e23f1b-07 bridge     qbre7e23f1b-07 virtio      fa:16:3e:72:ad:53

[heat-admin@overcloud-novacompute-1 ~]$

අපි Compute-0 හි br-int හි ඉදිරියට යැවීමේ වගුව දෙස බලමු:

[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
    2     1  fa:16:3e:72:ad:53    1
[heat-admin@overcloud-novacompute-0 ~]

ගමනාගමනය වරාය 2 වෙත යා යුතුය - එය කුමන ආකාරයේ වරායක් දැයි බලමු:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$

මෙය patch-tun - එනම් br-tun හි අතුරු මුහුණතයි. අපි බලමු br-tun හි පැකේජයට කුමක් සිදුවේදැයි:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
 cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$

පැකට්ටුව VxLAN හි ඇසුරුම් කර වරාය 2 වෙත යවනු ලැබේ. අපි බලමු වරාය 2 යන්නේ කොතැනටද යන්න:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr   
 1(patch-int): addr:b2:d1:f8:21:96:66
 2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
 3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
 LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$

මෙය compute-1 හි vxlan උමගකි:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

Идем на compute-1 и смотрим, что дальше происходит с пакетом:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
    2     1  fa:16:3e:44:98:20    1
[heat-admin@overcloud-novacompute-1 ~]$

Mac පරිගණකය-1 හි br-int යොමු කිරීමේ වගුවේ ඇති අතර, ඉහත ප්‍රතිදානයෙන් දැකිය හැකි පරිදි, එය 2 වරාය හරහා දෘශ්‍යමාන වේ, එය br-tun දෙසට ඇති වරාය වේ:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr   
 1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
 2(patch-tun): addr:46:cc:40:bd:20:da
 3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
 4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
 LOCAL(br-int): addr:e2:27:b2:ed:14:46

හොඳයි, එවිට අපට පෙනෙන්නේ compute-1 හි br-int හි ගමනාන්ත පොපි වර්ගයක් ඇති බවයි:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
    3     1  fa:16:3e:72:ad:53    0
[heat-admin@overcloud-novacompute-1 ~]$

එනම්, ලැබුණු පැකට්ටුව වරාය 3 වෙත පියාසර කරනු ඇත, පිටුපස දැනටමත් අතථ්‍ය යන්ත්‍ර උදාහරණයක්-00000003 ඇත.

Вся прелесть развертывания Openstack для изучения на виртуальной инфраструктуре в том, что мы можем без проблем отловить трафик между гипервизорами и посмотреть, что происходит с ним. Это мы сейчас и сделаем, запустим tcpdump на vnet порту в сторону compute-0:


[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes

*****************omitted*******************

04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
	
*****************omitted*******************

Первая строка показывает, что патек с адрес 10.0.1.85 идет на адрес 10.0.1.88 (ICMP трафик), причем он завернут в VxLAN пакет с vni 22 и пакет идет с хоста 192.168.255.19 (compute-0) на хост 192.168.255.26 (compute-1). Можем проверить, что VNI соответствует тому, который указан в ovs.

අපි මෙම පේළියට ආපසු යමු ක්‍රියා = load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],ප්‍රතිදානය:2. 0x16 යනු ෂඩ් දශම සංඛ්‍යා පද්ධතියේ vni වේ. අපි මෙම අංකය 16 වන පද්ධතියට පරිවර්තනය කරමු:


16 = 6*16^0+1*16^1 = 6+16 = 22

එනම්, vni යථාර්ථයට අනුරූප වේ.

Вторая строка показывает обратный трафик, ну его пояснять нет смысла там и так все ясно.

Две машины в разных сетях (маршрутизация между сетями)

Последний кейс на сегодня — это маршрутизация между сетями внутри одного проекта с использованием виртуального маршрутизатора. Мы рассматриваем случай без DVR (его рассмотрим в другой статье), поэтому маршрутизация происходит на network ноде. В нашем случае network нода не вынесена в отдельную сущность и расположена на control ноде.

මුලින්ම අපි බලමු routing වැඩ කරනවද කියලා.

$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 ms

මෙම අවස්ථාවේ දී පැකට්ටුව ද්වාරය වෙත ගොස් එහි ගෙන යා යුතු බැවින්, අපි ද්වාරයෙහි MAC ලිපිනය සොයා ගත යුතුය, ඒ සඳහා අපි උදාහරණයක් ලෙස ARP වගුව දෙස බලමු:

$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether]  on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether]  on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether]  on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether]  on eth0

දැන් අපි බලමු ගමනාන්තය සහිත ගමනාගමනය (10.0.1.254) fa:16:3e:c4:64:70 යැවිය යුත්තේ කොතැනටද කියා:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
    2     1  fa:16:3e:c4:64:70    0
[heat-admin@overcloud-novacompute-0 ~]$

වරාය 2 යොමු කරන්නේ කොතැනටදැයි බලමු:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$

සෑම දෙයක්ම තාර්කිකයි, ගමනාගමනය br-tun වෙත යයි. අපි බලමු එය කුමන vxlan උමගකින් ඔතා ඇත්දැයි:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
 cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$

තෙවන වරාය vxlan උමගකි:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
 1(patch-int): addr:a2:69:00:c5:fa:ba
 2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
 3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
 LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$

Который смотрит на control ноду:

[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$

ගමනාගමනය පාලන නෝඩයට පැමිණ ඇති බැවින් අපි එයට ගොස් මාර්ගගත කිරීම සිදු වන්නේ කෙසේදැයි බැලිය යුතුය.

Как вы помните, контрольная нода внутри выглядела точно также как и compute нода — те же три бриджа, только у br-ex был физический порт, через который нода могла слать трафик наружу. Создание инстансов изменило конфигурацию на compute нодах — добавились linux bridge, iptables и интерфейсы в ноды. Создание сетей и виртуального маршрутизатора также оставило свой отпечаток на конфигурации control ноды.

එබැවින්, ගේට්වේ MAC ලිපිනය පාලක නෝඩයේ br-int යොමු කිරීමේ වගුවේ තිබිය යුතු බව පැහැදිලිය. එය එහි තිබේද සහ එය සොයන්නේ කොතැනදැයි පරීක්ෂා කරමු:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
    5     1  fa:16:3e:c4:64:70    1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$  sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:2e:58:b6:db:d5:de
 2(patch-tun): addr:06:41:90:f0:9e:56
 3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
 4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
 5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
 6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
 LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$

Мак виден из порта qr-0c52b15f-8f. Если вернуться обратно к списку виртуальных портов в Openstack, то этот тип порта используется для подключения к OVS различных виртуальных устройств. Если быть точнее qr — это порт в сторону виртуального маршрутизатора, который представлена в виде namespace.

සේවාදායකයේ ඇති නාම අවකාශයන් මොනවාදැයි බලමු:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$

පිටපත් තුනක් තරම්. නමුත් නම් අනුව විනිශ්චය කිරීමෙන් ඔබට ඒවායින් එක් එක් අරමුණ අනුමාන කළ හැකිය. අපි පසුව ID 0 සහ 1 සමඟ නිදසුන් වෙත ආපසු යමු, දැන් අපි namespace qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ගැන උනන්දු වෙමු:


[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254 
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254 
[heat-admin@overcloud-controller-0 ~]$

මෙම නාම අවකාශයේ අප කලින් නිර්මාණය කළ අභ්‍යන්තර ඒවා දෙකක් අඩංගු වේ. virtual port දෙකම br-int වෙත එකතු කර ඇත. ගමනාන්ත mac ලිපිනය අනුව විනිශ්චය කිරීම, ගමනාගමනය මෙම අතුරුමුහුණත වෙත ගිය බැවින්, qr-0c52b15f-8f වරායේ mac ලිපිනය පරීක්ෂා කරමු.

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.0.1.254  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fec4:6470  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:c4:64:70  txqueuelen 1000  (Ethernet)
        RX packets 5356  bytes 427305 (417.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5195  bytes 490603 (479.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$

То есть в данном случае все работает по законам стандартной маршрутизации. Так как трафик предназначен хосту 10.0.2.8, то он должен выйти через второй интерфейс qr-92fa49b5-54 и уйти через vxlan тоннель на compute ноду:


[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address                  HWtype  HWaddress           Flags Mask            Iface
10.0.1.88                ether   fa:16:3e:72:ad:53   C                     qr-0c52b15f-8f
10.0.1.90                ether   fa:16:3e:83:ad:a4   C                     qr-0c52b15f-8f
10.0.2.8                 ether   fa:16:3e:6c:ad:9c   C                     qr-92fa49b5-54
10.0.2.42                ether   fa:16:3e:f5:0b:29   C                     qr-92fa49b5-54
10.0.1.85                ether   fa:16:3e:44:98:20   C                     qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$

සෑම දෙයක්ම තර්කානුකූලයි, පුදුමයක් නැත. අපි බලමු ධාරක 10.0.2.8 හි පොපි ලිපිනය br-int හි දිස්වන්නේ කොතැනදැයි:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
    2     2  fa:16:3e:6c:ad:9c    1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:2e:58:b6:db:d5:de
 2(patch-tun): addr:06:41:90:f0:9e:56
 3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
 4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
 5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
 6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
 LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$

බලාපොරොත්තු වූ පරිදි, ගමනාගමනය br-tun වෙත යයි, අපි බලමු මීළඟට තදබදය යන්නේ කුමන උමං මාර්ගයටද යන්න:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
 cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
 1(patch-int): addr:a2:69:00:c5:fa:ba
 2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
 3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
 LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$

1 ගණනය කිරීම සඳහා රථවාහන උමග තුළට යයි. හොඳයි, compute-1 හි සියල්ල සරලයි - br-tun සිට පැකේජය br-int වෙත ගොස් එතැන් සිට අතථ්‍ය යන්ත්‍ර අතුරුමුහුණත වෙත යයි:

[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
    4     2  fa:16:3e:6c:ad:9c    1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr                  
 1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
 2(patch-tun): addr:46:cc:40:bd:20:da
 3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
 4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
 LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$

මෙය ඇත්ත වශයෙන්ම නිවැරදි අතුරු මුහුණත දැයි පරීක්ෂා කර බලමු:

[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.02429c001e1c       no
qbr3210e8ec-c0          8000.ea27f45358be       no              qvb3210e8ec-c0
                                                        tap3210e8ec-c0
qbre7e23f1b-07          8000.b26ac0eded8a       no              qvbe7e23f1b-07
                                                        tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$ 
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge     qbr3210e8ec-c0 virtio      fa:16:3e:6c:ad:9c

[heat-admin@overcloud-novacompute-1 ~]$

ඇත්ත වශයෙන්ම, අපි පැකේජය හරහා ගියෙමු. රථවාහන විවිධ vxlan උමං හරහා ගොස් විවිධ VNI සමඟ පිටව ගිය බව ඔබ දැක ඇතැයි මම සිතමි. මේවා කුමන ආකාරයේ VNI දැයි බලමු, ඉන්පසු අපි නෝඩයේ පාලන වරාය මත ඩම්ප් එකක් එකතු කර ඉහත විස්තර කර ඇති ආකාරයටම ගමනාගමනය ගලා යන බවට වග බලා ගන්නෙමු.
එබැවින්, ගණනය කිරීම-0 සඳහා උමඟට පහත ක්‍රියා ඇත=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],ප්‍රතිදානය:3. අපි 0x16 දශම සංඛ්යා පද්ධතියට පරිවර්තනය කරමු:


0x16 = 6*16^0+1*16^1 = 6+16 = 22

ගණනය කිරීම-1 සඳහා උමගෙහි පහත VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],ප්‍රතිදානය:2 ඇත. අපි 0x63 දශම සංඛ්යා පද්ධතියට පරිවර්තනය කරමු:


0x63 = 3*16^0+6*16^1 = 3+96 = 99

හොඳයි, දැන් අපි කුණු කූඩය දෙස බලමු:

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4 
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes

*****************omitted*******************

04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
	
*****************omitted*******************

පළමු පැකට්ටුව සත්කාරක 192.168.255.19 (පරිගණක-0) සිට vni 192.168.255.15 සමඟ සත්කාරක 1 (පාලනය-22) දක්වා vxlan පැකට්ටුවකි, ඇතුළත ICMP පැකට්ටුවක් සත්කාරක 10.0.1.85 සිට සත්කාරක 10.0.2.8 දක්වා ඇසුරුම් කර ඇත. අප ඉහත ගණනය කළ පරිදි, vni ප්‍රතිදානයේ අප දුටු දෙයට ගැලපේ.

Второй пакет — это vxlan пакет с хоста 192.168.255.15 (control-1) на хост 192.168.255.26 (compute-1) с vni 99, внутри которого упакован ICMP пакет с хоста 10.0.1.85 на хост 10.0.2.8. Как мы посчитали выше, vni соответствует тому, что мы видели в выводах.

Два следующих пакета — это обратный трафик с 10.0.2.8 не 10.0.1.85.

එනම්, අවසානයේ අපට පහත පාලන නෝඩ් යෝජනා ක්‍රමය ලැබුණි:

පේන විදියට ඒකද? අපට නාම අවකාශ දෙකක් ගැන අමතක විය:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$

අපි ක්ලවුඩ් වේදිකාවේ ගෘහ නිර්මාණ ශිල්පය ගැන කතා කළ පරිදි, යන්ත්‍රවලට DHCP සේවාදායකයකින් ස්වයංක්‍රීයව ලිපින ලැබුණොත් හොඳයි. මේවා අපගේ 10.0.1.0/24 සහ 10.0.2.0/24 ජාල දෙක සඳහා DHCP සේවාදායකයන් දෙකකි.

මෙය සත්‍ය දැයි පරීක්ෂා කර බලමු. මෙම නාම අවකාශයේ ඇත්තේ එක් ලිපිනයක් පමණි - 10.0.1.1 - DHCP සේවාදායකයේම ලිපිනය වන අතර එය br-int හි ද ඇතුළත් වේ:

[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1  bytes 28 (28.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1  bytes 28 (28.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.0.1.1  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fee6:2c5c  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:e6:2c:5c  txqueuelen 1000  (Ethernet)
        RX packets 129  bytes 9372 (9.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 49  bytes 6154 (6.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Посмотрим, если процессы содержащие в своем названии qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 на control ноде:


[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 
root      640420  0.0  0.0   4220   348 ?        Ss   11:31   0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+  951620  0.0  0.0 112944   980 pts/0    S+   18:50   0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$

Есть такой процесс и исходя из информации, представленной в выводе выше мы можем например посмотреть, что у нас в аренде в настоящий момент:

[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$

В итоге мы получаем вот такой набор сервисов на control ноде:

හොඳයි, මතක තබා ගන්න - මෙය යන්ත්‍ර 4 ක්, අභ්‍යන්තර ජාල 2 ක් සහ එක් අතථ්‍ය රවුටරයක් පමණි... අපට දැන් මෙහි බාහිර ජාල නොමැත, විවිධ ව්‍යාපෘති සමූහයක්, එකකට තමන්ගේම ජාල (අතිච්ඡාදනය වන), සහ අප සතුව ඇත. බෙදා හරින ලද රවුටරයක් ක්‍රියා විරහිත කර ඇති අතර, අවසානයේදී, පරීක්ෂණ බංකුවේ තිබුණේ එක් පාලන නෝඩයක් පමණි (වැරදි ඉවසීම සඳහා නෝඩ් තුනක ගණපූරණයක් තිබිය යුතුය). වාණිජ්‍යයේදී සෑම දෙයක්ම “ටිකක්” වඩා සංකීර්ණ බව තාර්කික ය, නමුත් මෙම සරල උදාහරණයෙන් එය ක්‍රියා කළ යුතු ආකාරය අපට වැටහේ - ඔබට නාම අවකාශයන් 3 ක් හෝ 300 ක් තිබේද යන්න ඇත්ත වශයෙන්ම වැදගත් වේ, නමුත් සමස්ත ක්‍රියාකාරිත්වයේ දෘෂ්ටි කෝණයෙන් ව්‍යුහය, කිසිවක් විශාල වශයෙන් වෙනස් නොවනු ඇත... නමුත් ඔබ යම් විකුණුම්කරුවෙකු SDN සම්බන්ධ නොකරන තුරු. නමුත් එය සම්පූර්ණයෙන්ම වෙනස් කතාවකි.

Надеюсь было интересно. Если есть замечания/дополнения ну или где то я откровенно соврал (я человек и мое мнение всегда будет субъективно) — пишите что надо поправить/добавить — все поправим/добавим.

අවසාන වශයෙන්, VMWare වෙතින් වන ක්ලවුඩ් විසඳුම සමඟ Openstack (වැනිලා සහ වෙළෙන්දා යන දෙකම) සංසන්දනය කිරීම ගැන වචන කිහිපයක් පැවසීමට මම කැමැත්තෙමි - පසුගිය වසර කිහිපය තුළ මගෙන් මෙම ප්‍රශ්නය බොහෝ විට අසන ලද අතර, අවංකව කිවහොත්, මම දැනටමත් මහන්සියි, නමුත් තවමත්. මගේ මතය අනුව, මෙම විසඳුම් දෙක සංසන්දනය කිරීම ඉතා අපහසුය, නමුත් විසඳුම් දෙකෙහිම අවාසි ඇති බව අපට නිසැකවම පැවසිය හැකි අතර එක් විසඳුමක් තෝරාගැනීමේදී ඔබ වාසි සහ අවාසි කිරා මැන බැලිය යුතුය.

OpenStack ප්‍රජාව විසින් මෙහෙයවන විසඳුමක් නම්, VMWare හට තමන්ට අවශ්‍ය දේ පමණක් කිරීමට අයිතියක් ඇත (කියවන්න - එයට ලාභදායී දේ) සහ මෙය තාර්කික ය - මන්ද එය තම සේවාදායකයින්ගෙන් මුදල් ඉපැයීමට පුරුදු වී සිටින වාණිජ සමාගමකි. නමුත් විශාල හා මහත එකක් ඇත නමුත් - ඔබට OpenStack වෙතින් ඉවත් විය හැකිය, උදාහරණයක් ලෙස Nokia වෙතින්, සහ සුළු වියදමකින් විසඳුමකට මාරු විය හැකිය, උදාහරණයක් ලෙස, Juniper (Contrail Cloud), නමුත් ඔබට VMWare වෙතින් ඉවත් වීමට නොහැකි වනු ඇත. . මට නම්, මෙම විසඳුම් දෙක පෙනෙන්නේ මේ ආකාරයටයි - Openstack (වෙළෙන්දා) යනු ඔබව තබා ඇති සරල කූඩුවකි, නමුත් ඔබට යතුරක් ඇති අතර ඔබට ඕනෑම වේලාවක පිටවිය හැකිය. VMWare යනු රන් කූඩුවකි, කූඩුවේ යතුර අයිතිකරු සතුව ඇති අතර එය ඔබට විශාල මුදලක් වැය වනු ඇත.

මම පළමු නිෂ්පාදනය හෝ දෙවැන්න ප්‍රවර්ධනය නොකරමි - ඔබට අවශ්‍ය දේ ඔබ තෝරා ගන්න. නමුත් මට එවැනි තේරීමක් තිබුනේ නම්, මම විසඳුම් දෙකම තෝරා ගනිමි - IT ක්ලවුඩ් සඳහා VMWare (අඩු බර, පහසු කළමනාකරණය), සමහර වෙළෙන්දන්ගෙන් OpenStack (Nokia සහ Juniper ඉතා හොඳ පිරිවැටුම් විසඳුම් සපයයි) - Telecom cloud සඳහා. මම පිරිසිදු තොරතුරු තාක්‍ෂණය සඳහා Openstack භාවිතා නොකරමි - එය හරියට කාලතුවක්කුවකින් ගේ කුරුල්ලන්ට වෙඩි තැබීම වැනිය, නමුත් අතිරික්තය හැර එය භාවිතා කිරීමට කිසිදු ප්‍රතිවිරෝධයක් මට නොපෙනේ. කෙසේ වෙතත්, ටෙලිකොම් හි VMWare භාවිතා කිරීම Ford Raptor එකක තලා දැමූ ගල් ඇදගෙන යාම වැනි ය - එය පිටතින් ලස්සනයි, නමුත් රියදුරුට එකක් වෙනුවට චාරිකා 10 ක් කළ යුතුය.

මගේ මතය අනුව, VMWare හි ඇති ලොකුම අවාසිය නම් එහි සම්පූර්ණ වසා දැමීමයි - සමාගම ඔබට එය ක්‍රියා කරන ආකාරය පිළිබඳ කිසිදු තොරතුරක් ලබා නොදේ, උදාහරණයක් ලෙස, vSAN හෝ හයිපර්වයිසර් කර්නලයේ ඇති දේ - එය සරලවම එයට ලාභදායී නොවේ - එනම්, ඔබ කිසි විටෙකත් VMWare හි ප්‍රවීණයෙකු නොවන්න - විකුණුම්කරුවන්ගේ සහාය නොමැතිව, ඔබ විනාශයට පත්වේ (බොහෝ විට මට සුළු ප්‍රශ්නවලින් ව්‍යාකූල වන VMWare විශේෂඥයින් හමුවෙයි). මට නම්, VMWare හුඩ් අගුලු දමා ඇති මෝටර් රථයක් මිලදී ගනී - ඔව්, ඔබට කාල පටිය වෙනස් කළ හැකි විශේෂ ists යින් සිටිය හැකිය, නමුත් ඔබට මෙම විසඳුම විකුණු තැනැත්තාට පමණක් කබාය විවෘත කළ හැකිය. පුද්ගලිකව, මට නොගැලපෙන විසඳුම් වලට මම කැමති නැහැ. ඔබට තොප්පිය යටට යාමට සිදු නොවිය හැකි බව ඔබ කියනු ඇත. ඔව්, මෙය කළ හැකි ය, නමුත් ඔබට අථත්‍ය යන්ත්‍ර 20-30 කින්, ජාල 40-50 කින් විශාල කාර්යයක් වලාකුළෙහි එකලස් කිරීමට අවශ්‍ය වූ විට මම ඔබ දෙස බලන්නම්, එයින් අඩක් පිටතට යාමට අවශ්‍ය වන අතර දෙවන භාගය ඉල්ලා සිටී. SR-IOV ත්වරණය, එසේ නොමැතිනම් ඔබට මෙම මෝටර් රථ දුසිම් කිහිපයක් අවශ්‍ය වනු ඇත - එසේ නොමැතිනම් කාර්ය සාධනය ප්‍රමාණවත් නොවේ.

වෙනත් දෘෂ්ටි කෝණයන් ඇත, එබැවින් තෝරා ගත යුතු දේ තීරණය කළ හැක්කේ ඔබට පමණක් වන අතර, වඩාත්ම වැදගත් දෙය නම්, ඔබේ තේරීම සඳහා ඔබ වගකිව යුතුය. මෙය මගේ මතය පමණි - Nokia, Juniper, Red Hat සහ VMWare නිෂ්පාදන 4ක් වත් දැක ඇති සහ ස්පර්ශ කර ඇති පුද්ගලයෙක්. එනම්, මට සංසන්දනය කිරීමට යමක් තිබේ.

මූලාශ්රය: www.habr.com

වලාකුළු යටිතල ව්‍යුහයේ ජාල කොටසට හැඳින්වීම

Что такое облако? Та же виртуализация — вид в профиль?

අපට වලාකුළක් අවශ්‍ය වන්නේ ඇයි?

OpenStack යනු කුමක්ද?

නියුට්‍රෝන ගෘහ නිර්මාණ ශිල්පය

Следует сразу уточнить, что Neutron не является SDN контроллером.

මොඩියුලර් ස්ථරය 2

අපි Open vSwitch මත මදින්න

මෙය සැබෑ පිරිසැලසුමක ක්‍රියා කරන්නේ කෙසේද?

යට වලාකුළු ස්ථාපනය

අධි ක්ලවුඩ් ස්ථාපනය

Две машины на одном гипервизоре в одной L2 сети

Две машины в разных сетях (маршрутизация между сетями)

අදහස් එක් කරන්න

වලාකුළු යටිතල ව්‍යුහයේ ජාල කොටසට හැඳින්වීම

Что такое облако? Та же виртуализация — вид в профиль?

අපට වලාකුළක් අවශ්‍ය වන්නේ ඇයි?

OpenStack යනු කුමක්ද?

නියුට්‍රෝන ගෘහ නිර්මාණ ශිල්පය

Следует сразу уточнить, что Neutron не является SDN контроллером.

මොඩියුලර් ස්ථරය 2

අපි Open vSwitch මත මදින්න

මෙය සැබෑ පිරිසැලසුමක ක්‍රියා කරන්නේ කෙසේද?

යට වලාකුළු ස්ථාපනය

අධි ක්ලවුඩ් ස්ථාපනය

Две машины на одном гипервизоре в одной L2 сети

Две машины в разных сетях (маршрутизация между сетями)

අදහස් එක් කරන්න ඊ-මේල් මගින් පිලිතුරු දෙන්න අවලංගු

අදහස් එක් කරන්න