Linux හි බොහෝ මුහුණු ඇත: ඕනෑම බෙදාහැරීමක් මත වැඩ කරන්නේ කෙසේද

ඕනෑම බෙදාහැරීමක් මත වැඩ කරන උපස්ථ යෙදුමක් නිර්මාණය කිරීම පහසු කාර්යයක් නොවේ. Linux සඳහා Veeam නියෝජිතයා Red Hat 6 සහ Debian 6 සිට OpenSUSE 15.1 සහ Ubuntu 19.04 දක්වා බෙදාහැරීම් මත ක්‍රියා කරන බව සහතික කිරීම සඳහා, මෘදුකාංග නිෂ්පාදනයට කර්නල් මොඩියුලයක් ඇතුළත් වන බව සැලකිල්ලට ගනිමින්, ඔබට ගැටළු රාශියක් විසඳා ගත යුතුය.

මෙම ලිපිය සම්මන්ත්‍රණයේ දී කරන ලද කතාවක ද්‍රව්‍ය මත පදනම්ව නිර්මාණය කරන ලදී ලිනක්ස් පීටර් 2019.

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

පැකේජ කළමනාකරුවන්. .deb එදිරිව .rpm

විවිධ බෙදාහැරීම් හරහා භාණ්ඩය බෙදා හැරීමේ පැහැදිලි ගැටලුව සමඟ ආරම්භ කරමු.
මෘදුකාංග නිෂ්පාදන බෙදා හැරීමේ වඩාත් සාමාන්‍ය ක්‍රමය නම් පැකේජය ගබඩාවක් මත තැබීමයි, එවිට පද්ධතිය තුළ ගොඩනගා ඇති පැකේජ කළමනාකරුට එය එතැනින් ස්ථාපනය කළ හැකිය.
කෙසේ වෙතත්, අපට ජනප්‍රිය පැකේජ ආකෘති දෙකක් තිබේ: rpm වේ и deb. මෙයින් අදහස් කරන්නේ සෑම කෙනෙකුටම සහයෝගය දැක්වීමට සිදුවනු ඇති බවයි.

ඩෙබ් පැකේජ ලෝකයේ, ගැළපුම් මට්ටම පුදුම සහගතය. එකම පැකේජය Debian 6 සහ Ubuntu 19.04 යන දෙකෙහිම සමානව ස්ථාපනය කර ක්‍රියා කරයි. පැරණි ඩේබියන් බෙදාහැරීම්වල දක්වා ඇති පැකේජ ගොඩනැගීමේ ක්‍රියාවලියේ සහ ඒවා සමඟ වැඩ කිරීමේ ක්‍රියාවලිය සඳහා වන ප්‍රමිතීන් නව ලිනක්ස් මින්ට් සහ මූලික මෙහෙයුම් පද්ධතිය තුළ අදාළ වේ. එබැවින්, Linux සඳහා Veeam Agent සම්බන්ධයෙන්, සෑම දෘඪාංග වේදිකාවක් සඳහාම එක් deb පැකේජයක් ප්රමාණවත් වේ.

නමුත් rpm පැකේජ ලෝකයේ, වෙනස්කම් විශාලයි. පළමුව, Red Hat සහ SUSE යන සම්පූර්ණයෙන්ම ස්වාධීන බෙදාහරින්නන් දෙදෙනෙකු සිටින නිසා, ඒ සඳහා ගැළපුම සම්පූර්ණයෙන්ම අනවශ්‍යයි. දෙවනුව, මෙම බෙදාහරින්නන්ට ඒවායින් බෙදා හැරීමේ කට්ටල තිබේ. සහාය සහ පර්යේෂණාත්මක. ඔවුන් අතර ගැළපීමක් ද අවශ්‍ය නොවේ. el6, el7 සහ el8 ඔවුන්ගේම පැකේජ ඇති බව පෙනී ගියේය. Fedora සඳහා වෙනම පැකේජයක්. SLES11 සහ 12 සඳහා පැකේජ සහ openSUSE සඳහා වෙනම එකක්. ප්රධාන ගැටළුව වන්නේ පරායත්තතා සහ පැකේජ නම් වේ.

යැපුම් ගැටලුව

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

EL7 සඳහා:
SLES 12 සඳහා:

• libblkid
• libgcc
• libstdc++
• ncurses-libs
• ෆියුස්-ලිබ්ස්
• ගොනු-ලිබ්ස්
• veamsnap=3.0.2.1185

• libblkid1
• libgcc_s1
• libstdc++6
• libmagic1
• libfuse2
• veamsnap-kmp=3.0.2.1185

එහි ප්රතිඵලයක් වශයෙන්, බෙදා හැරීම සඳහා යැපීම් ලැයිස්තුව අද්විතීය වේ.

වඩාත් නරක වන්නේ යාවත්කාලීන කළ අනුවාදයක් පැරණි පැකේජ නාමය යටතේ සැඟවීමට පටන් ගන්නා විටය.

උදාහරණ:

පැකේජය Fedora 24 හි යාවත්කාලීන කර ඇත ශාප කරයි 5 වන අනුවාදයේ සිට 6 වන අනුවාදය දක්වා. අපගේ නිෂ්පාදනය පැරණි බෙදාහැරීම් සමඟ ගැළපෙන බව සහතික කිරීම සඳහා 5 අනුවාදය සමඟ ගොඩනගා ඇත. Fedora 5 හි පුස්තකාලයේ පැරණි 24 වන අනුවාදය භාවිතා කිරීමට, මට පැකේජය භාවිතා කිරීමට සිදු විය ncurses-compat-libs.

එහි ප්‍රතිඵලයක් වශයෙන්, Fedora සඳහා විවිධ පරායත්තතා සහිත පැකේජ දෙකක් ඇත.

තවත් රසවත්. ඊළඟ බෙදාහැරීමේ යාවත්කාලීන කිරීමෙන් පසුව, පැකේජය ncurses-compat-libs පුස්තකාලයේ 5 අනුවාදය සමඟ එය ලබා ගත නොහැක. බෙදාහරින්නෙකුට පැරණි පුස්තකාල බෙදාහැරීමේ නව අනුවාදයකට ඇදගෙන යාම මිල අධිකය. ටික වේලාවකට පසු, ගැටළුව SUSE බෙදාහැරීම් තුළ නැවත නැවතත් සිදු විය.

එහි ප්‍රතිඵලයක් වශයෙන්, සමහර බෙදාහැරීම්වලට ඒවායේ පැහැදිලි යැපීම අත්හැරීමට සිදු විය ncurses-libs, සහ පුස්තකාලයේ ඕනෑම අනුවාදයක් සමඟ වැඩ කිරීමට හැකි වන පරිදි නිෂ්පාදනය සවි කරන්න.

මාර්ගය වන විට, Red Hat හි 8 වන අනුවාදයේ තවදුරටත් මෙටා පැකේජයක් නොමැත පිඹුරා, හොඳ පැරණි ගැන සඳහන් පයිතන් 2.7. ඇත පයිතන්එන්එන්එක්ස් и පිඹුරා3.

පැකේජ කළමනාකරුවන් සඳහා විකල්පයක්

පරායත්තතාවයන් පිළිබඳ ගැටළුව පැරණි වන අතර දිගු කලක් තිස්සේ පැහැදිලිය. යැපුම් මඟුල මතක තබා ගන්න.
විවිධ පුස්තකාල සහ යෙදුම් ඒකාබද්ධ කිරීම සඳහා ඒවා සියල්ලම ස්ථාවරව ක්‍රියා කරන අතර ගැටුම් ඇති නොවන පරිදි - ඇත්ත වශයෙන්ම, ඕනෑම ලිනක්ස් බෙදාහරින්නෙකු විසඳීමට උත්සාහ කරන කාර්යය මෙයයි.

පැකේජ කළමනාකරු මෙම ගැටළුව සම්පූර්ණයෙන්ම වෙනස් ආකාරයකින් විසඳීමට උත්සාහ කරයි. ස්නැපි කැනොනිකල් වෙතින්. ප්‍රධාන අදහස: යෙදුම ක්‍රියාත්මක වන්නේ ප්‍රධාන පද්ධතියෙන් හුදකලා වූ සහ ආරක්ෂිත වැලි පෙට්ටියක ය. යෙදුමකට පුස්තකාල අවශ්‍ය නම්, ඒවා යෙදුම සමඟම සපයනු ලැබේ.

ෆ්ලැට්ප්ක් ලිනක්ස් බහාලුම් භාවිතයෙන් වැලිපිල්ලක යෙදුම් ධාවනය කිරීමටද ඔබට ඉඩ සලසයි. වැලිපිල්ල අදහස ද භාවිතා වේ AppImage.

මෙම විසඳුම් ඔබට ඕනෑම බෙදාහැරීමක් සඳහා එක් පැකේජයක් නිර්මාණය කිරීමට ඉඩ සලසයි. අවස්ථාවක ෆ්ලැට්ප්ක් පරිපාලකගේ අනුදැනුමකින් තොරව වුවද යෙදුම ස්ථාපනය කිරීම සහ දියත් කිරීම කළ හැකිය.

ප්‍රධාන ගැටළුව වන්නේ සියලුම යෙදුම් වැලි පෙට්ටියක ක්‍රියාත්මක විය නොහැකි වීමයි. සමහර අයට වේදිකාවට සෘජු ප්‍රවේශය අවශ්‍ය වේ. මම කර්නලය මත දැඩි ලෙස රඳා පවතින සහ වැලිපිල්ල සංකල්පයට නොගැලපෙන කර්නල් මොඩියුල ගැන කතා නොකරමි.

දෙවන ගැටළුව නම්, Red Hat සහ SUSE වෙතින් ව්‍යවසාය පරිසරයේ ජනප්‍රිය බෙදාහැරීම් තවමත් Snappy සහ Flatpak සඳහා සහය අඩංගු නොවීමයි.

මේ සම්බන්ධයෙන්, Linux සඳහා Veeam නියෝජිතයා නොමැත snapcraft.io මත නොවේ flathub.org.

පැකේජ කළමනාකරුවන් පිළිබඳ ප්‍රශ්නය අවසන් කිරීම සඳහා, ද්විමය ගොනු සහ ඒවා එක් පැකේජයකට ස්ථාපනය කිරීම සඳහා ස්ක්‍රිප්ට් එක ඒකාබද්ධ කිරීමෙන් පැකේජ කළමනාකරුවන් සම්පූර්ණයෙන්ම අත්හැරීමේ විකල්පයක් ඇති බව සටහන් කිරීමට කැමැත්තෙමි.

එවැනි මිටියක් ඔබට විවිධ බෙදාහැරීම් සහ වේදිකා සඳහා එක් පොදු පැකේජයක් නිර්මාණය කිරීමට ඉඩ සලසයි, අන්තර් ක්රියාකාරී ස්ථාපන ක්රියාවලියක් සිදු කිරීම, අවශ්ය අභිරුචිකරණය සිදු කිරීම. මම ලිනක්ස් සඳහා එවැනි පැකේජ හමු වී ඇත්තේ VMware වෙතින් පමණි.

යාවත්කාලීන ගැටළුව

සියලු පරායත්ත ගැටළු නිරාකරණය වුවද, වැඩසටහන එකම බෙදාහැරීම මත වෙනස් ලෙස ක්‍රියාත්මක විය හැක. එය යාවත්කාලීන පිළිබඳ කාරණයකි.

යාවත්කාලීන උපාය මාර්ග 3 ක් ඇත:

• සරලම දෙය නම් කිසි විටෙකත් යාවත්කාලීන නොකිරීමයි. සර්වර් එක සෙට් කරලා ඒක අමතක උනා. සියල්ල ක්‍රියාත්මක වන්නේ නම් යාවත්කාලීන කරන්නේ ඇයි? ඔබ සහය සම්බන්ධ කර ගත් පළමු අවස්ථාවේදීම ගැටළු ආරම්භ වේ. බෙදා හැරීමේ නිර්මාතෘ යාවත්කාලීන නිකුතුවට පමණක් සහාය දක්වයි.
• ඔබට බෙදාහරින්නා විශ්වාස කර ස්වයංක්‍රීය යාවත්කාල කිරීම් පිහිටුවිය හැක. මෙම අවස්ථාවෙහිදී, අසාර්ථක යාවත්කාලීනයකින් පසු වහාම සහාය සඳහා ඇමතුමක් විය හැකිය.
• පරීක්ෂණ යටිතල පහසුකම් මත ධාවනය කිරීමෙන් පසුව පමණක් අතින් යාවත්කාලීන කිරීමේ විකල්පය වඩාත්ම විශ්වාසදායක, නමුත් මිල අධික හා කාලය ගත වේ. සෑම කෙනෙකුටම එය දැරිය නොහැක.

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

දෘඪාංග වේදිකාවල විවිධත්වය

විවිධ දෘඪාංග වේදිකා බොහෝ දුරට ස්වදේශීය කේතයට විශේෂිත වූ ගැටළුවකි. අවම වශයෙන්, ඔබට සහාය දක්වන එක් එක් වේදිකාව සඳහා ද්විමය එකතු කිරීමට සිදුවේ.

Linux ව්‍යාපෘතිය සඳහා Veeam නියෝජිතයා තුළ, අපට තවමත් මෙම RISC වැනි දෙයකට සහාය දැක්විය නොහැක.

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

ස්ථිතික සහ/හෝ ගතික සම්බන්ධ කිරීම

නමුත් ප්‍රශ්නය වන්නේ “පුස්තකාල සමඟ සම්බන්ධ කරන්නේ කෙසේද - ගතිකව හෝ ස්ථිතිකව?” යන්නයි. සාකච්ඡා කිරීම වටී.

රීතියක් ලෙස, ලිනක්ස් යටතේ ඇති C/C++ යෙදුම් ගතික සම්බන්ධ කිරීම භාවිතා කරයි. යෙදුම නිශ්චිත බෙදාහැරීමක් සඳහා විශේෂයෙන් ගොඩනගා ඇත්නම් මෙය ඉතා හොඳින් ක්‍රියා කරයි.

කාර්යය වන්නේ එක් ද්විමය ගොනුවකින් විවිධ බෙදාහැරීම් ආවරණය කිරීම නම්, ඔබ පැරණිතම සහය දක්වන බෙදාහැරීම කෙරෙහි අවධානය යොමු කළ යුතුය. අපට නම්, මෙය Red Hat 6 වේ. එහි gcc 4.4 අඩංගු වේ, C++11 ප්‍රමිතිය පවා එයට සහාය නොදක්වයි. සම්පූර්ණයෙන්ම.

අපි අපගේ ව්‍යාපෘතිය ගොඩනගන්නේ Gcc 6.3 භාවිතයෙන් වන අතර එය C++14 සඳහා සම්පුර්ණයෙන්ම සහය දක්වයි. ස්වාභාවිකවම, මෙම අවස්ථාවේදී, Red Hat 6 මත ඔබට libstdc++ රැගෙන යා යුතු අතර ඔබ සමඟ පුස්තකාල වැඩි කළ යුතුය. පහසුම ක්රමය වන්නේ ඒවාට ස්ථිතිකව සම්බන්ධ කිරීමයි.

නමුත් අහෝ, සියලුම පුස්තකාල ස්ථිතිකව සම්බන්ධ කළ නොහැක.

පළමුව, පද්ධති පුස්තකාල වැනි ලිබ්ෆියුස්, libblkid කර්නලය සහ එහි මොඩියුල සමග ඒවායේ ගැළපුම සහතික කිරීම සඳහා ගතිකව සම්බන්ධ කිරීම අවශ්ය වේ.

දෙවනුව, බලපත්ර සමඟ සූක්ෂ්මතාවයක් ඇත.

GPL බලපත්‍රය මූලික වශයෙන් ඔබට විවෘත කේත සමඟ පමණක් පුස්තකාල සම්බන්ධ කිරීමට ඉඩ සලසයි. MIT සහ BSD ස්ථිතික සම්බන්ධ කිරීමට ඉඩ දෙන අතර ව්‍යාපෘතියකට පුස්තකාල ඇතුළත් කිරීමට ඉඩ සලසයි. නමුත් LGPL ස්ථිතික සබැඳියට පටහැනි බවක් නොපෙනේ, නමුත් සම්බන්ධ කිරීම සඳහා අවශ්‍ය ගොනු බෙදාගැනීම අවශ්‍ය වේ.

පොදුවේ ගත් කල, ගතික සම්බන්ධ කිරීම භාවිතා කිරීමෙන් ඔබට කිසිවක් සැපයීමෙන් වලක්වනු ඇත.

C/C++ යෙදුම් ගොඩනැගීම

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

පැහැදිලි වාසියක්: සමස්ත ගොඩනැගීමේ ක්‍රියාවලිය එක් යන්ත්‍රයකින් සම්පූර්ණ කළ හැකි බැවින් යටිතල පහසුකම් බෙහෙවින් සරල කර ඇත. මීට අමතරව, එක් ගෘහ නිර්මාණ ශිල්පයක් සඳහා ද්විමය කට්ටලයක් එකතු කිරීම ප්රමාණවත් වන අතර විවිධ බෙදාහැරීම් සඳහා පැකේජ වලට ඒවා ඇසුරුම් කළ හැකිය. Linux සඳහා Veeam Agent සඳහා veeam පැකේජ ගොඩනගා ඇත්තේ එලෙසයි.

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

කෙසේ වෙතත්, මෙම ප්‍රවේශයේ අවාසියක් ඇත: එකම ගෘහ නිර්මාණ ශිල්පය තුළ එක් එක් බෙදාහැරීම සඳහා, ඔබට ඔබේම ද්විමය ගොනු එකතු කිරීමට සිදුවේ. තවත් අවාසියක් නම් මෙතරම් විශාල යන්ත්‍ර ප්‍රමාණයක් නඩත්තු කිරීමට අවශ්‍ය වන අතර විශාල තැටි ඉඩක් සහ RAM ප්‍රමාණයක් වෙන් කළ යුතුය.

veeamsnap කර්නල් මොඩියුලයේ KMOD පැකේජ Red Hat බෙදාහැරීම් සඳහා සම්පාදනය කරන්නේ මෙලෙසිනි.

ගොඩනැගීමේ සේවාව විවෘත කරන්න

SUSE හි සගයන් යෙදුම් සම්පාදනය කිරීම සහ පැකේජ එකලස් කිරීම සඳහා විශේෂ සේවාවක් ආකාරයෙන් සමහර මැද බිමක් ක්‍රියාත්මක කිරීමට උත්සාහ කළහ - openbuildservice.

අත්‍යවශ්‍යයෙන්ම, එය අථත්‍ය යන්ත්‍රයක් නිර්මාණය කරන, අවශ්‍ය සියලුම පැකේජ එහි ස්ථාපනය කර, යෙදුම සම්පාදනය කර මෙම හුදකලා පරිසරය තුළ පැකේජය ගොඩනඟන හයිපර්වයිසර් එකක් වන අතර ඉන් පසුව අථත්‍ය යන්ත්‍රය මුදා හරිනු ලැබේ.

OpenBuildService හි ක්‍රියාත්මක කරන ලද උපලේඛනය ප්‍රශස්ත පැකේජ ගොඩනැගීමේ වේගය සඳහා කොපමණ අතථ්‍ය යන්ත්‍ර ප්‍රමාණයක් දියත් කළ හැකිද යන්න තීරණය කරයි. සාදන ලද අත්සන් කිරීමේ යාන්ත්‍රණය පැකේජ අත්සන් කර ඒවා ගොඩනඟන ලද ගබඩාවට උඩුගත කරනු ඇත. බිල්ට් අනුවාද පාලන පද්ධතිය වෙනස්වීම් සහ ගොඩනැගීම් ඉතිහාසය සුරකිනු ඇත. ඉතිරිව ඇත්තේ ඔබේ මූලාශ්‍ර මෙම පද්ධතියට එක් කිරීම පමණි. ඔබට සේවාදායකය ඔබ විසින්ම සැකසීමට අවශ්‍ය නැත; ඔබට විවෘත එකක් භාවිතා කළ හැකිය.

කෙසේ වෙතත්, ගැටළුවක් තිබේ: එවැනි අස්වනු නෙලන යන්ත්රයක් පවතින යටිතල පහසුකම් වලට ගැලපීම දුෂ්කර ය. උදාහරණයක් ලෙස, අනුවාද පාලනය අවශ්‍ය නොවේ; ප්‍රභව කේත සඳහා අපට දැනටමත් අපගේම ඇත. අපගේ අත්සන යාන්ත්‍රණය වෙනස් ය: අපි විශේෂ සේවාදායකයක් භාවිතා කරමු. ගබඩාවක් ද අවශ්‍ය නොවේ.

මීට අමතරව, අනෙකුත් බෙදාහැරීම් සඳහා සහය - උදාහරණයක් ලෙස, Red Hat - තරමක් දුර්වල ලෙස ක්‍රියාත්මක වේ, එය තේරුම් ගත හැකිය.

එවැනි සේවාවක වාසිය වන්නේ SUSE බෙදාහැරීමේ ඊළඟ අනුවාදය සඳහා වේගවත් සහායයි. නිකුතුව පිළිබඳ නිල නිවේදනයට පෙර, එකලස් කිරීම සඳහා අවශ්ය පැකේජ පොදු ගබඩාවක පළ කරනු ලැබේ. OpenBuildService හි පවතින බෙදාහැරීම් ලැයිස්තුවේ නව එකක් දිස්වේ. අපි කොටුව පරීක්ෂා කර එය ගොඩනැගීමේ සැලැස්මට එකතු කරනු ලැබේ. මේ අනුව, බෙදා හැරීමේ නව අනුවාදයක් එකතු කිරීම එක් ක්ලික් කිරීමකින් පාහේ සිදු කෙරේ.

අපගේ යටිතල ව්‍යුහය තුළ, OpenBuildService භාවිතයෙන්, SUSE බෙදාහැරීම් සඳහා වීම්ස්නැප් කර්නල් මොඩියුලයේ සම්පූර්ණ විවිධ KMP පැකේජ එකලස් කර ඇත.

මීළඟට, කර්නල් මොඩියුල සඳහා විශේෂිත වූ ගැටළු පිළිබඳව මම වාසය කිරීමට කැමැත්තෙමි.

කර්නලය ABI

ලිනක්ස් කර්නල් මොඩියුල ඓතිහාසිකව ප්‍රභව ආකාරයෙන් බෙදා හැර ඇත. කාරණය නම් කර්නලයේ නිර්මාපකයින් කර්නල් මොඩියුල සඳහා ස්ථාවර API සඳහා සහය දැක්වීම ගැන සැලකිලිමත් නොවීම සහ විශේෂයෙන් ද්විමය මට්ටමින්, තවදුරටත් kABI ලෙස හැඳින්වේ.

වැනිලා කර්නලයක් සඳහා මොඩියුලයක් තැනීම සඳහා, ඔබට මෙම විශේෂිත කර්නලයේ ශීර්ෂයන් අනිවාර්යයෙන්ම අවශ්‍ය වන අතර එය ක්‍රියා කරන්නේ මෙම කර්නලය මත පමණි.

කර්නලය යාවත්කාලීන කිරීමේදී මොඩියුල ගොඩනැගීමේ ක්‍රියාවලිය ස්වයංක්‍රීය කිරීමට DKMS ඔබට ඉඩ සලසයි. එහි ප්‍රතිඵලයක් වශයෙන්, Debian ගබඩාවේ පරිශීලකයන් (සහ එහි බොහෝ ඥාතීන්) බෙදාහරින්නාගේ ගබඩාවෙන් හෝ DKMS භාවිතයෙන් මූලාශ්‍රයෙන් සම්පාදනය කරන ලද කර්නල් මොඩියුල භාවිතා කරයි.

කෙසේ වෙතත්, මෙම තත්ත්වය ව්යවසාය අංශයට විශේෂයෙන් ගැලපෙන්නේ නැත. හිමිකාර කේත බෙදාහරින්නන්ට නිෂ්පාදනය සම්පාදනය කරන ලද ද්විමය ලෙස බෙදා හැරීමට අවශ්‍ය වේ.

ආරක්ෂක හේතූන් මත නිෂ්පාදන සේවාදායක මත සංවර්ධන මෙවලම් තබා ගැනීමට පරිපාලකයින්ට අවශ්‍ය නැත. Red Hat සහ SUSE වැනි Enterprise Linux බෙදාහරින්නන් ඔවුන්ගේ පරිශීලකයින් සඳහා ස්ථාවර kABI සඳහා සහාය විය හැකි බව තීරණය කළහ. එහි ප්‍රතිඵලය වූයේ Red Hat සඳහා KMOD පැකේජ සහ SUSE සඳහා KMP පැකේජයි.

මෙම විසඳුමේ සාරය තරමක් සරල ය. බෙදාහැරීමේ නිශ්චිත අනුවාදයක් සඳහා, කර්නල් API කැටි කර ඇත. බෙදාහරින්නා පවසන්නේ ඔහු කර්නලය භාවිතා කරන බවයි, උදාහරණයක් ලෙස, 3.10, සහ කර්නල් අතුරුමුහුණත්වලට බලපාන්නේ නැති නිවැරදි කිරීම් සහ වැඩිදියුණු කිරීම් පමණක් සිදු කරන අතර, පළමු කර්නලය සඳහා එකතු කරන ලද මොඩියුල නැවත සම්පාදනයකින් තොරව සියලුම පසු ඒවා සඳහා භාවිතා කළ හැකිය.

Red Hat සිය සම්පූර්ණ ජීවන චක්‍රය පුරා බෙදාහැරීම සඳහා kABI අනුකූලතාවයට හිමිකම් කියයි. එනම්, rhel 6.0 සඳහා එකලස් කරන ලද මොඩියුලය (නොවැම්බර් 2010 නිකුත් කිරීම) 6.10 අනුවාදයේ (2018 ජූනි නිකුත් කිරීම) ද ක්‍රියා කළ යුතුය. ඒ වගේම මේක අවුරුදු 8ක් විතර වෙනවා. ස්වාභාවිකවම, මෙම කාර්යය තරමක් දුෂ්කර ය.
kABI ගැළපුම් ගැටළු හේතුවෙන් veeamsnap මොඩියුලය ක්‍රියා විරහිත වූ අවස්ථා කිහිපයක් අපි වාර්තා කර ඇත.

RHEL 7.0 සඳහා සම්පාදනය කරන ලද veeamsnap මොඩියුලය RHEL 7.5 වෙතින් වන කර්නලය සමඟ නොගැලපෙන නමුත් එය පූරණය වී සේවාදායකය බිඳ වැටීමට සහතික වූ පසු, අපි RHEL 7 සඳහා kABI ගැළපුම භාවිතය සම්පූර්ණයෙන්ම අත්හැර දැමුවෙමු.

දැනට, RHEL 7 සඳහා වන KMOD පැකේජයේ සෑම නිකුතුවක් සඳහාම එකලස් කිරීමක් සහ මොඩියුලය පූරණය කරන ස්ක්‍රිප්ට් එකක් අඩංගු වේ.

SUSE විසින් kABI ගැළපුම පිළිබඳ කාර්යය වඩාත් ප්රවේශමෙන් ප්රවේශ විය. ඔවුන් kABI අනුකූලතාව ලබා දෙන්නේ එක් සේවා පැකේජයක් තුළ පමණි.

උදාහරණයක් ලෙස, SLES 12 නිකුත් කිරීම 2014 සැප්තැම්බර් මාසයේදී සිදු විය. තවද SLES 12 SP1 දැනටමත් 2015 දෙසැම්බර් මාසයේදී එනම්, වසරකට වඩා ටිකක් වැඩි කාලයක් ගතවී ඇත. නිකුතු දෙකම 3.12 කර්නලය භාවිතා කළද, ඒවා kABI නොගැලපේ. නිසැකවම, වසරක් සඳහා kABI අනුකූලතාව පවත්වා ගැනීම වඩාත් පහසු වේ. වාර්ෂික කර්නල් මොඩියුල යාවත්කාලීන චක්‍රය මොඩියුල නිර්මාපකයින් සඳහා ගැටළු ඇති නොකළ යුතුය.

මෙම SUSE ප්‍රතිපත්තියේ ප්‍රතිඵලයක් ලෙස, අපි අපගේ veeamsnap මොඩියුලයේ kABI ගැළපුම පිළිබඳ එකදු ගැටලුවක්වත් සටහන් කර නැත. ඇත්ත, SUSE සඳහා පැකේජ ගණන බොහෝ දුරට විශාලත්වයේ අනුපිළිවෙලකි.

පැච් සහ බැක්පෝට්

බෙදාහරින්නන් kABI ගැළපුම සහ කර්නල් ස්ථායිතාව සහතික කිරීමට උත්සාහ කළද, ඔවුන් මෙම ස්ථාවර කර්නලයේ ක්‍රියාකාරීත්වය වැඩිදියුණු කිරීමට සහ දෝෂ ඉවත් කිරීමට උත්සාහ කරයි.

ඒ අතරම, ඔවුන්ගේම "දෝෂ මත වැඩ" වලට අමතරව, ව්යවසාය ලිනක්ස් කර්නල් මොනිටරයේ සංවර්ධකයින් වැනිලා කර්නලයේ වෙනස්කම් සිදු කර ඔවුන්ගේ "ස්ථායී" එකට මාරු කරයි.

සමහර විට මෙය නව ඒවාට මග පාදයි වැරදි.

Red Hat 6 හි නවතම නිකුතුවේදී, සුළු යාවත්කාලීන කිරීම් වලින් එකක වැරදීමක් සිදු විය. එය ස්නැප්ෂොට් නිකුත් කරන විට veeamsnap මොඩියුලය පද්ධතිය බිඳ වැටීමට සහතික විය. යාවත්කාලීන කිරීමට පෙර සහ පසු කර්නල් ප්‍රභවයන් සංසන්දනය කිරීමෙන් පසු, බැක්පෝට් එකට දොස් පැවරිය යුතු බව අපට පෙනී ගියේය. වැනිලා කර්නල් අනුවාදය 4.19 හි සමාන විසඳුමක් සිදු කරන ලදී. මෙම නිවැරදි කිරීම වැනිලා කර්නලයේ හොඳින් ක්‍රියාත්මක වූ නමුත් එය “ස්ථාවර” 2.6.32 වෙත මාරු කිරීමේදී, ස්පින්ලොක් සමඟ ගැටළුවක් ඇති විය.

ඇත්ත වශයෙන්ම, සෑම විටම සෑම කෙනෙකුටම දෝෂ ඇත, නමුත් ස්ථාවරත්වය අවදානමට ලක් කරමින් කේතය 4.19 සිට 2.6.32 දක්වා ඇදගෙන යාම වටී ද?.. මට විශ්වාස නැත...

නරකම දෙය වන්නේ අලෙවිකරණය "ස්ථාවරත්වය" සහ "නවීකරණය" අතර කඹ ඇදීමට සම්බන්ධ වීමයි. අලෙවිකරණ දෙපාර්තමේන්තුවට එක් අතකින් ස්ථාවර වීමටත්, ඒ සමඟම කාර්ය සාධනයෙන් වඩා හොඳ වීමටත් නව විශේෂාංග තිබීමටත් යාවත්කාලීන බෙදාහැරීමේ හරය අවශ්‍ය වේ. මෙය අමුතු සම්මුතීන් වලට මග පාදයි.

මම SLES 4.4 SP12 වෙතින් කර්නල් 3 මත මොඩියුලයක් තැනීමට උත්සාහ කළ විට, එහි වැනිලා 4.8 හි ක්‍රියාකාරීත්වය සොයා ගැනීම ගැන මම පුදුමයට පත් විය. මගේ මතය අනුව, SLES 4.4 SP12 වෙතින් 3 කර්නලයේ වාරණ I/O ක්‍රියාත්මක කිරීම SLES4.8 SP4.4 වෙතින් ස්ථායී 12 කර්නලයේ පෙර නිකුතුවට වඩා 2 කර්නලයට සමාන වේ. SP4.8 සඳහා kernel 4.4 සිට SLES 3 වෙත මාරු කර ඇති කේතයේ ප්‍රතිශතය කොපමණ දැයි මට විනිශ්චය කළ නොහැක, නමුත් මට කර්නලය එකම ස්ථාවර 4.4 ලෙස ඇමතීමට පවා නොහැකිය.

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

එහි ප්‍රතිඵලයක් වශයෙන්, කේතය අමුතු කොන්දේසි සහිත සම්පාදන විධානයන්ගෙන් පිරී යයි.

ලේඛනගත කර්නල් API වෙනස් කරන පැච් ද ඇත.
බෙදා හැරීම මට හමු විය කේඩී නියොන් 5.16 සහ මෙම කර්නල් අනුවාදයේ lookup_bdev ඇමතුම ආදාන පරාමිති ලැයිස්තුව වෙනස් කිරීම දැකීමෙන් පුදුමයට පත් විය.

එය එකතු කර ගැනීම සඳහා, lookup_bdev ශ්‍රිතයට මාස්ක් පරාමිතියක් තිබේදැයි පරීක්ෂා කරන Script එකක් makefile වෙත එක් කිරීමට මට සිදු විය.

කර්නල් මොඩියුල අත්සන් කිරීම

නමුත් පැකේජ බෙදා හැරීමේ ගැටලුව වෙත ආපසු යමු.

ස්ථාවර kABI හි ඇති එක් වාසියක් නම් කර්නල් මොඩියුල ද්විමය ගොනුවක් ලෙස අත්සන් කළ හැකි වීමයි. මෙම අවස්ථාවේදී, මොඩියුලය අහම්බෙන් හානි වී හෝ හිතාමතාම වෙනස් කර නොමැති බව සංවර්ධකයාට සහතික විය හැකිය. ඔබට modinfo විධානය සමඟ මෙය පරීක්ෂා කළ හැකිය.

Red Hat සහ SUSE බෙදාහැරීම් මඟින් ඔබට මොඩියුලයේ අත්සන පරීක්ෂා කර එය පූරණය කිරීමට ඉඩ ලබා දෙන්නේ අදාල සහතිකය පද්ධතියේ ලියාපදිංචි වී ඇත්නම් පමණි. සහතිකය යනු මොඩියුලය අත්සන් කර ඇති පොදු යතුරයි. අපි එය වෙනම පැකේජයක් ලෙස බෙදා හරිමු.

මෙහි ඇති ගැටළුව නම් සහතික කර්නලය තුළට ගොඩනැගිය හැකිය (බෙදාහරින්නන් ඒවා භාවිතා කරයි) නැතහොත් උපයෝගීතාවයක් භාවිතයෙන් EFI වාෂ්පශීලී නොවන මතකයට ලිවිය යුතුය. mokutil. උපයෝගිතා mokutil සහතිකයක් ස්ථාපනය කරන විට, එය ඔබට පද්ධතිය නැවත ආරම්භ කිරීමට අවශ්‍ය වන අතර, මෙහෙයුම් පද්ධති කර්නලය පූරණය කිරීමට පෙර පවා, නව සහතිකයක් පැටවීමට ඉඩ දෙන ලෙස පරිපාලකගෙන් විමසයි.

මේ අනුව, සහතිකයක් එකතු කිරීම සඳහා පද්ධතියට භෞතික පරිපාලක ප්‍රවේශය අවශ්‍ය වේ. යන්ත්‍රය වලාකුළේ කොතැනක හෝ දුරස්ථ සේවාදායක කාමරයක පිහිටා තිබේ නම් සහ ප්‍රවේශය ජාලය හරහා පමණක් නම් (උදාහරණයක් ලෙස, ssh හරහා), එවිට සහතිකයක් එක් කිරීමට නොහැකි වනු ඇත.

අතථ්‍ය යන්ත්‍ර මත EFI

සියලුම මවු පුවරු නිෂ්පාදකයින් විසින් EFI දිගු කලක් තිස්සේ සහාය ලබා දී ඇතත්, පද්ධතියක් ස්ථාපනය කරන විට, පරිපාලකයා EFI හි අවශ්‍යතාවය ගැන නොසිතිය හැකි අතර එය අක්‍රිය විය හැකිය.

සියලුම හයිපර්වයිසර් EFI සඳහා සහය නොදක්වයි. VMWare vSphere 5 අනුවාදයේ සිට EFI සඳහා සහය දක්වයි.
Microsoft Hyper-V Windows Server 2012R2 සඳහා Hyper-V සමඟින් ආරම්භ වන EFI සහාය ද ලබා ගත්තේය.

කෙසේ වෙතත්, පෙරනිමි වින්‍යාසය තුළ මෙම ක්‍රියාකාරීත්වය Linux යන්ත්‍ර සඳහා අක්‍රිය කර ඇත, එනම් සහතිකය ස්ථාපනය කළ නොහැක.

vSphere 6.5 හි, විකල්පය සකසන්න ආරක්ෂිත ඇරඹුම් ෆ්ලෑෂ් හරහා ධාවනය වන වෙබ් අතුරු මුහුණතේ පැරණි අනුවාදයේ පමණක් හැකි ය. HTML-5 හි වෙබ් UI තවමත් බොහෝ පසුපසින් සිටී.

පර්යේෂණාත්මක බෙදාහැරීම්

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

කෙසේ වෙතත්, එවැනි බෙදාහැරීම් නව පර්යේෂණාත්මක විසඳුම් අත්හදා බැලීම සඳහා පහසු වේදිකාවක් බවට පත්වේ. උදාහරණයක් ලෙස, Fedora, OpenSUSE Tumbleweed හෝ Debian හි අස්ථායී අනුවාද. ඒවා තරමක් ස්ථාවරයි. ඔවුන් සෑම විටම වැඩසටහන් වල නව අනුවාදයන් සහ සෑම විටම නව කර්නලයක් ඇත. වසරක් තුළ, මෙම පර්යේෂණාත්මක ක්‍රියාකාරීත්වය යාවත්කාලීන කළ RHEL, SLES හෝ Ubuntu එකකින් අවසන් විය හැක.

එබැවින් පර්යේෂණාත්මක බෙදාහැරීමක් මත යමක් ක්රියා නොකරන්නේ නම්, මෙය ගැටළුව සොයා ගැනීමට සහ එය විසඳීමට හේතුවකි. මෙම ක්‍රියාකාරිත්වය ඉක්මනින් පරිශීලකයින්ගේ නිෂ්පාදන සේවාදායකයන්හි දිස්වනු ඇති බවට ඔබ සූදානම් විය යුතුය.

ඔබට 3.0 අනුවාදය සඳහා නිල වශයෙන් සහාය දක්වන බෙදාහැරීම් ලැයිස්තුව අධ්‍යයනය කළ හැකිය මෙහි. නමුත් අපගේ නිෂ්පාදනයට වැඩ කළ හැකි බෙදාහැරීමේ සැබෑ ලැයිස්තුව වඩා පුළුල් ය.

පුද්ගලිකව, මම Elbrus OS සමඟ අත්හදා බැලීම ගැන උනන්දු විය. Veeam පැකේජය අවසන් කිරීමෙන් පසුව, අපගේ නිෂ්පාදනය ස්ථාපනය කර වැඩ කරන ලදී. මම Habré හි මෙම අත්හදා බැලීම ගැන ලිව්වා ලිපියයි.

හොඳයි, නව බෙදාහැරීම් සඳහා සහය දිගටම පවතී. 4.0 අනුවාදය නිකුත් කිරීමට අපි බලා සිටිමු. බීටා දර්ශනය වීමට ආසන්නයි, එබැවින් විමසිල්ලෙන් සිටින්න මොනවද අළුත්!

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