Ар кандай бөлүштүрүүдө иштеген резервдик тиркемени түзүү оңой иш эмес. Linux үчүн Veeam Агенттин Red Hat 6 жана Debian 6, OpenSUSE 15.1 жана Ubuntu 19.04 дистрибуцияларында иштешин камсыз кылуу үчүн, сиз бир катар маселелерди чечишиңиз керек, айрыкча программалык продукт ядро модулун камтыганын эске алуу менен.
Макала конференцияда сүйлөгөн сөзүнүн материалдарынын негизинде түзүлдү .
Linux эң популярдуу операциялык системалардын бири эмес. Негизи, бул платформа, анын негизинде сиз уникалдуу, өзүңүздүн бир нерсени жасай аласыз. Ушунун аркасында Linux программалык камсыздоо компоненттеринин топтому менен айырмаланган көптөгөн дистрибьюцияларга ээ. Жана бул жерде бир маселе туулат: программалык продукт кандайдыр бир бөлүштүрүүдө иштеши үчүн, ар биринин өзгөчөлүктөрүн эске алуу керек.
Пакет менеджерлери. .deb vs .rpm
Продукцияны түрдүү бөлүштүрүүлөр боюнча бөлүштүрүүнүн ачык көйгөйүнөн баштайлы.
Программалык продуктыларды жайылтуунун эң типтүү жолу - пакетти репозиторийге коюу, системага орнотулган пакет менеджери аны ошол жерден орното алат.
Бирок, бизде эки популярдуу пакет форматтары бар: об и Деб. Бул ар бир адам колдоо керек дегенди билдирет.
Деб пакеттер дүйнөсүндө шайкештиктин деңгээли укмуштуудай. Ошол эле пакет Debian 6 жана Ubuntu 19.04 экөө тең орнотулуп, бирдей жакшы иштейт. Эски Debian дистрибуцияларында белгиленген пакеттерди түзүү жана алар менен иштөө процессинин стандарттары жаңы Linux Mint жана элементардык ОС үчүн актуалдуу бойдон калууда. Ошондуктан, Linux үчүн Veeam Agent учурда, ар бир аппараттык платформа үчүн бир deb пакети жетиштүү.
Бирок rpm пакеттеринин дүйнөсүндө айырмачылыктар чоң. Биринчиден, эки толугу менен көз карандысыз дистрибьюторлор бар экенине байланыштуу, Red Hat жана SUSE, алар үчүн шайкештик таптакыр керексиз. Экинчиден, бул дистрибьюторлор ошолордон бөлүштүрүүчү комплекттерге ээ. колдоо жана эксперименталдык. Алардын ортосунда да шайкештиктин кереги жок. El6, el7, el8 дегендердин өздөрүнүн пакеттери бар экен. Fedora үчүн өзүнчө пакет. SLES11 жана 12 үчүн топтомдор жана openSUSE үчүн өзүнчө. Негизги көйгөй - көз карандылыктар жана пакеттердин аталыштары.
Көз карандылык маселеси
Тилекке каршы, бир эле пакеттер көп учурда ар кандай бөлүштүрүүдө ар кандай аталыштар менен аяктайт. Төмөндө veeam пакетинин көз карандылыктарынын жарым-жартылай тизмеси келтирилген.
EL7 үчүн:
SLES 12 үчүн:
- libblkid
- libgcc
- libstdc++
- ncurses-libs
- fuse-libs
- файл-libs
- veeamsnap=3.0.2.1185
- libblkid1
- libgcc_s1
- libstdc++6
- libmagic1
- libfuse2
- veeamsnap-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. бар python2 и код3.
Пакет менеджерлерине альтернатива
Көз карандылыктын көйгөйү эски жана эчак эле ачык болуп келген. Көз карандылыктын тозогун эсте.
Ар кандай китепканаларды жана тиркемелерди бириктирүү үчүн, алардын баары туруктуу иштеши жана карама-каршылык болбошу үчүн - чындыгында, бул Linux дистрибьютору чечүүгө аракет кылган милдет.
Пакет менеджери бул маселени такыр башка жол менен чечүүгө аракет кылат. Бат Canonical тартып. Негизги идея: тиркеме негизги системадан обочолонгон жана корголгон кум чөйрөсүндө иштейт. Эгер колдонмо китепканаларды талап кылса, алар тиркеменин өзү менен берилет.
Flatpak ошондой эле Linux Контейнерлерин колдонуп, кумкоргондо колдонмолорду иштетүүгө мүмкүнчүлүк берет. Кумкоргон идеясы да колдонулат AppImage.
Бул чечимдер ар кандай бөлүштүрүү үчүн бир пакетти түзүүгө мүмкүндүк берет. болгон учурда Flatpak колдонмону орнотуу жана ишке киргизүү администратордун билбесе да мүмкүн.
Негизги көйгөй - бардык тиркемелер кумкоргондо иштей албайт. Кээ бир адамдар платформага түз жетүү керек. Мен ядродон катуу көз каранды болгон жана кумкоргон концепциясына туура келбеген ядро модулдары жөнүндө да айткан жокмун.
Экинчи маселе - Red Hat жана SUSE компанияларынын чөйрөсүндө популярдуу болгон дистрибьюторлор Snappy жана Flatpak үчүн колдоону камтыбайт.
Бул жагынан алганда, Linux үчүн Veeam Agent жеткиликтүү эмес күйүк эмес .
Пакет менеджерлери жөнүндө суроону жыйынтыктоо үчүн, экилик файлдарды жана аларды бир пакетке орнотуу үчүн скриптти бириктирүү аркылуу пакет менеджерлеринен таптакыр баш тартуу мүмкүнчүлүгү бар экенин белгилегим келет.
Мындай таңгак ар кандай дистрибуциялар жана платформалар үчүн бир жалпы пакетти түзүүгө, керектүү ыңгайлаштырууларды жүргүзүү менен интерактивдүү орнотуу процессин жүргүзүүгө мүмкүндүк берет. Мен VMwareден Linux үчүн мындай пакеттерди гана жолуктурдум.
Жаңыртуу маселеси
Бардык көз карандылык маселелери чечилсе да, программа бир эле бөлүштүрүүдө башкача иштеши мүмкүн. Бул жаңыртуулар маселеси.
3 жаңыртуу стратегиясы бар:
- Эң жөнөкөйсү - эч качан жаңырбоо. Мен серверди орнотуп, аны унутуп калдым. Баары иштесе, эмне үчүн жаңыртыңыз? Көйгөйлөр колдоо кызматына биринчи жолу кайрылганыңызда башталат. Бөлүштүрүүнүн жаратуучусу жаңыртылган чыгарууну гана колдойт.
- Сиз дистрибьюторго ишенип, автоматтык жаңыртууларды орното аласыз. Бул учурда, колдоого чалуу ийгиликсиз жаңыртуудан кийин дароо болушу мүмкүн.
- Аны тесттик инфраструктурада иштеткенден кийин гана кол менен жаңыртуу варианты эң ишенимдүү, бирок кымбат жана көп убакытты талап кылат. Ар кимдин эле колунан келе бербейт.
Ар кандай колдонуучулар ар кандай жаңыртуу стратегияларын колдонгондуктан, акыркы релиздерди да, мурда чыгарылгандардын бардыгын колдоо керек. Бул иштеп чыгуу жана тестирлөө процессин татаалдаштырып, колдоо тобуна баш ооруну кошот.
Ар түрдүү аппараттык платформалар
Ар кандай аппараттык платформалар негизинен жергиликтүү кодго мүнөздүү болгон көйгөй. Жок дегенде, ар бир колдоого алынган платформа үчүн бинарларды чогултушуңуз керек.
Veeam Agent for Linux долбоорунда биз дагы эле бул RISC сыяктуу эч нерсени колдой албайбыз.
Мен бул маселеге кеңири токтолбойм. Мен негизги көйгөйлөрдү гана белгилейм: платформага көз каранды түрлөрү, мисалы size_t, структураны тегиздөө жана байт тартиби.
Статикалык жана/же динамикалык байланыш
Бирок суроо "Китепканалар менен кантип байланышса болот - динамикалык же статикалык?" талкуулоого татыктуу.
Эреже катары, Linux астындагы C/C++ тиркемелери динамикалык байланышты колдонушат. Бул колдонмо атайын бир бөлүштүрүү үчүн курулган болсо, жакшы иштейт.
Эгерде тапшырма бир бинардык файл менен ар кандай бөлүштүрүүнү камтуу болсо, анда сиз эң эски колдоого алынган бөлүштүрүүгө басым жасашыңыз керек. Биз үчүн бул Red Hat 6. Анда gcc 4.4 камтылган, ал тургай C++11 стандарты да колдобойт. .
Биз долбоорду толугу менен C++ 6.3 колдогон gcc 14 менен курабыз. Албетте, бул учурда, Red Hat 6да сиз libstdc++ алып жүрүшүңүз керек жана китепканаларды өркүндөтүшүңүз керек. Эң оңой жолу - аларга статикалык байланыш түзүү.
Бирок, тилекке каршы, бардык китепканалар статикалык байланышта болушу мүмкүн эмес.
Биринчиден, системалык китепканалар, мисалы libfuse, libblkid алардын ядро жана анын модулдары менен шайкеш келишин камсыз кылуу үчүн динамикалык байланыштыруу зарыл.
Экинчиден, лицензиянын бир тымызын жагы бар.
GPL лицензиясы негизинен китепканаларды ачык код менен гана байланыштырууга мүмкүндүк берет. MIT жана BSD статикалык байланышты камсыз кылат жана китепканаларды долбоорго кошууга мүмкүндүк берет. Бирок LGPL статикалык шилтемеге карама-каршы келбейт окшойт, бирок шилтемелөө үчүн керектүү файлдарды бөлүшүүнү талап кылат.
Жалпысынан алганда, динамикалык байланышты колдонуу сизди эч нерсе менен камсыз кылуудан сактайт.
C/C++ тиркемелерин куруу
Ар кандай платформалар жана дистрибуциялар үчүн C/C++ тиркемелерин куруу үчүн gccтин ылайыктуу версиясын тандоо же куруу жана конкреттүү архитектуралар үчүн кайчылаш компиляторлорду колдонуу жана китепканалардын бардык топтомун чогултуу жетиштүү. Бул иш абдан мүмкүн, бирок бир топ түйшүктүү. Жана тандалган компилятор жана китепканалар иштей турган версияны камсыздайт деген кепилдик жок.
Айкын артыкчылыгы: инфраструктура абдан жөнөкөйлөштүрүлгөн, анткени бүт куруу процессин бир машинада бүтүрсө болот. Мындан тышкары, бир архитектура үчүн экиликтердин бир топтомун чогултуу жетиштүү жана аларды ар кандай бөлүштүрүүлөр үчүн пакеттерге топтосоңуз болот. Veeam пакеттери Linux үчүн Veeam Agent үчүн ушундайча түзүлөт.
Бул параметрден айырмаланып, сиз жөн гана куруу чарбасын, башкача айтканда, чогултуу үчүн бир нече машиналарды даярдай аласыз. Ар бир мындай машина белгилүү бир бөлүштүрүү жана белгилүү бир архитектура үчүн тиркемелердин компиляциясын жана пакетти чогултууну камсыз кылат. Бул учурда, компиляция дистрибьютор тарабынан даярдалган каражаттарды колдонуу менен жүзөгө ашырылат. Башкача айтканда, компиляторду даярдоо жана китепканаларды тандоо этабы жок кылынат. Мындан тышкары, куруу процессин оңой параллелдештирүүгө болот.
Бирок, бул ыкманын терс жагы бар: бир эле архитектурадагы ар бир бөлүштүрүү үчүн экилик файлдардын өзүңүздүн топтомун чогултушуңуз керек болот. Дагы бир кемчилиги - мынчалык көп сандагы машиналарды кармап туруу жана чоң көлөмдөгү диск мейкиндигин жана оперативдүү эсту бөлүштүрүү керек.
Red Hat дистрибьютерлери үчүн veeamsnap ядро модулунун KMOD пакеттери ушундайча түзүлөт.
Build Service ачыңыз
SUSE кесиптештери тиркемелерди түзүү жана пакеттерди чогултуу үчүн атайын кызмат түрүндө кандайдыр бир орто жерди ишке ашырууга аракет кылышкан - .
Негизи бул гипервизор, ал виртуалдык машинаны түзүп, андагы бардык керектүү пакеттерди орнотуп, тиркемени компиляциялайт жана пакетти ушул обочолонгон чөйрөдө курат, андан кийин виртуалдык машина чыгарылат.
OpenBuildServiceде ишке ашырылган пландаштыргыч пакетти куруунун оптималдуу ылдамдыгы үчүн канча виртуалдык машинаны ишке киргизе аларын аныктайт. Камтылган кол коюу механизми пакеттерге кол коюп, аларды камтылган репозиторийге жүктөйт. Камтылган версия башкаруу системасы өзгөртүүлөр жана куруу тарыхын сактап калат. Бул системага булактарыңызды кошуу гана калды. Серверди өзүңүз орнотуунун кереги жок; сиз ачык серверди колдоно аласыз.
Бирок, бир маселе бар: мындай комбайнды бар инфраструктурага батыруу кыйын. Мисалы, версияны башкаруунун кереги жок; бизде баштапкы коддор үчүн өзүбүздүн кодубуз бар. Биздин кол коюу механизмибиз башкача: биз атайын серверди колдонобуз. Репозиторийдин да кереги жок.
Мындан тышкары, башка дистрибуцияларды колдоо - мисалы, Red Hat - абдан начар ишке ашырылган, бул түшүнүктүү.
Мындай кызматтын артыкчылыгы SUSE бөлүштүрүүнүн кийинки версиясын тез колдоо болуп саналат. Чыгарылганы расмий жарыяланганга чейин чогултуу үчүн зарыл болгон пакеттер коомдук репозиторийге жайгаштырылат. Жаңысы OpenBuildServiceде жеткиликтүү бөлүштүрүүлөр тизмесинде пайда болот. Биз кутучаны белгилейбиз жана ал куруу планына кошулат. Ошентип, бөлүштүрүүнүн жаңы версиясын кошуу дээрлик бир чыкылдатуу менен жүзөгө ашырылат.
Биздин инфраструктурабызда OpenBuildService аркылуу SUSE дистрибуциялары үчүн veeamsnap ядро модулунун KMP пакеттеринин бардык түрү чогултулган.
Андан кийин, мен ядро модулдарына тиешелүү маселелерге токтолгум келет.
ядро ABI
Linux ядросунун модулдары тарыхый жактан булак түрүндө таратылган. Чындыгында, ядронун жаратуучулары ядро модулдары үчүн туруктуу API колдоо түйшүгүн өздөрүнө жүктөшпөйт, айрыкча бинардык деңгээлде, андан ары kABI деп аталат.
Ваниль ядросу үчүн модулду куруу үчүн, сизге так ушул ядронун аталыштары керек жана ал ушул ядродо гана иштейт.
DKMS ядрону жаңылоодо модулдарды куруу процессин автоматташтырууга мүмкүндүк берет. Натыйжада, Debian репозиторийинин колдонуучулары (жана анын көптөгөн туугандары) дистрибьютордун репозиторийинен же DKMS аркылуу булактан түзүлгөн өзөк модулдарын колдонушат.
Бирок, бул жагдай Enterprise сегментине өзгөчө туура келбейт. Проприетардык код дистрибьюторлору продуктту компиляцияланган бинарлар катары жайылтууну каалашат.
Администраторлор коопсуздук себептерден улам иштеп чыгуу куралдарын өндүрүш серверлеринде сактагысы келбейт. 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 жыл. Албетте, бул милдет өтө татаал.
Биз veeamsnap модулу kABI шайкештик маселелеринен улам иштебей калган бир нече учурларды каттадык.
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 шайкештигин жана ядронун туруктуулугун камсыз кылууга аракет кылышса да, бул туруктуу ядронун иштешин жакшыртууга жана кемчиликтерин жоюуга аракет кылышат.
Ошол эле учурда, өздөрүнүн "каталардын үстүндө иштөөдөн" тышкары, Linux ядросунун иштеп чыгуучулары ваниль өзөгүндөгү өзгөрүүлөргө көз салып, аларды "туруктуу" бирине өткөрүп беришет.
Кээде бул жаңысына алып келет .
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 үчүн ядро 4.4ден SLES 3кө которулганын айта албайм, бирок ядрону ошол эле туруктуу 4.4 деп да айта албайм.
Мунун эң жагымсыз жери, ар кандай ядролордо бирдей жакшы иштей турган модулду жазып жатканда, мындан ары ядро версиясына таяна албайсыз. Бөлүштүрүүнү да эске алуу керек. Кээде жаңы функциялар менен бирге пайда болгон аныктамага аралаша турганыңыз жакшы, бирок бул мүмкүнчүлүк дайыма эле пайда боло бербейт.
Натыйжада, код кызыктай шарттуу компиляция директивалары менен толуп калат.
Документтештирилген ядро API'син өзгөрткөн тактар да бар.
Мен бөлүштүрүүгө туш келдим 5.16 жана бул ядро версиясындагы lookup_bdev чалуу киргизүү параметрлеринин тизмесин өзгөрткөнүн көрүп абдан таң калдым.
Аны чогултуу үчүн makefile файлына lookup_bdev функциясынын маска параметри бар же жок экенин текшерген скрипт кошууга туура келди.
Ядро модулдарына кол коюу
Бирок пакетти бөлүштүрүү маселесине кайрылып көрөлү.
Туруктуу kABIнин артыкчылыктарынын бири ядро модулдарына бинардык файл катары кол коюуга болот. Бул учурда, иштеп чыгуучу модул кокустан бузулган же атайылап өзгөртүлгөн эмес деп ишене алат. Муну modinfo буйругу менен текшере аласыз.
Red Hat жана SUSE дистрибуциялары модулдун кол тамгасын текшерүүгө жана системада тиешелүү сертификат катталган учурда гана жүктөөгө мүмкүндүк берет. Сертификат модулга кол коюлган ачык ачкыч болуп саналат. Аны өзүнчө пакет кылып таратып жатабыз.
Бул жердеги маселе, сертификаттар ядрого салынышы мүмкүн (дистрибьюторлор аларды колдонушат) же Utility аркылуу 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те параметрди орнотуңуз коопсуз Жүктөөгүч Flash аркылуу иштеген веб-интерфейстин эски версиясында гана мүмкүн. HTML-5теги Web UI дагы эле артта.
Эксперименттик бөлүштүрүүлөр
Акыр-аягы, расмий колдоосу жок эксперименталдык бөлүштүрүү жана бөлүштүрүү маселесин карап көрөлү. Бир жагынан алганда, мындай бөлүштүрүү олуттуу уюмдардын серверлеринен табылышы күмөн. Мындай бөлүштүрүүгө расмий колдоо жок. Ошондуктан, аларды камсыз кылуу. Продукт мындай бөлүштүрүүдө колдоого алынбайт.
Бирок, мындай бөлүштүрүү жаңы эксперименталдык чечимдерди сынап көрүү үчүн ыңгайлуу платформа болуп калат. Мисалы, Fedora, OpenSUSE Tumbleweed же Debianдын туруксуз версиялары. Алар абдан туруктуу. Аларда ар дайым программалардын жаңы версиялары жана ар дайым жаңы ядро бар. Бир жылдан кийин бул эксперименталдык функция жаңыртылган RHEL, SLES же Ubuntu менен аякташы мүмкүн.
Ошентип, бир нерсе эксперименталдык бөлүштүрүү боюнча иштебесе, бул көйгөйдү аныктоо жана аны чечүү үчүн негиз болуп саналат. Бул функция жакында колдонуучулардын өндүрүш серверлеринде пайда боло турганына даяр болушуңуз керек.
Сиз 3.0 версиясы үчүн расмий түрдө колдоого алынган бөлүштүрүүнүн учурдагы тизмесин изилдей аласыз . Бирок биздин продукт иштей ала турган бөлүштүрүүнүн реалдуу тизмеси алда канча кенен.
Жеке мени Эльбрус OS менен эксперимент кызыктырды. veeam пакетин аяктагандан кийин, биздин продукт орнотулуп, иштеп баштады. Мен бул эксперимент жөнүндө Хабреде жаздым .
Ооба, жаңы бөлүштүрүү үчүн колдоо уланууда. Биз 4.0 версиясынын чыгышын күтүп жатабыз. Бета пайда болгону калды, андыктан абайлаңыз !
Source: www.habr.com