Кез келген таратуда жұмыс істейтін сақтық көшірме қолданбасын жасау оңай жұмыс емес. Veeam Agent for Linux бағдарламасының Red Hat 6 және Debian 6, OpenSUSE 15.1 және Ubuntu 19.04 дистрибутивтерінде жұмыс істеуін қамтамасыз ету үшін, әсіресе бағдарламалық өнімде ядро модулі бар екенін ескере отырып, бірқатар мәселелерді шешу керек.
Мақала конференцияда сөйлеген сөзінің материалдары негізінде жасалған .
Linux ең танымал операциялық жүйелердің бірі ғана емес. Негізінде, бұл платформа, оның негізінде сіз бірегей, өзіңізді бір нәрсе жасай аласыз. Осының арқасында Linux-та бағдарламалық құрал құрамдастарының жиынтығымен ерекшеленетін көптеген дистрибутивтер бар. Бұл жерде мәселе туындайды: бағдарламалық өнім кез келген дистрибутивте жұмыс істеуі үшін әрқайсысының ерекшеліктерін ескеру керек.
Пакет менеджерлері. .deb қарсы .айн/мин
Өнімді әртүрлі дистрибуциялар бойынша таратудың айқын мәселесінен бастайық.
Бағдарламалық жасақтама өнімдерін таратудың ең типтік тәсілі - жүйеге енгізілген пакет менеджері оны сол жерден орнатуы үшін пакетті репозиторийге қою.
Дегенмен, бізде екі танымал пакет пішімі бар: айн / мин и деп. Бұл әркім қолдау көрсетуі керек дегенді білдіреді.
Deb пакеттері әлемінде үйлесімділік деңгейі таңқаларлық. Бірдей пакет Debian 6 және Ubuntu 19.04 нұсқаларында бірдей жақсы орнатылады және жұмыс істейді. Ескі Debian дистрибутивтерінде белгіленген пакеттерді құру және олармен жұмыс істеу үдерісінің стандарттары жаңа Linux Mint және қарапайым ОЖ-де өзекті болып қала береді. Сондықтан Veeam Agent for Linux жағдайында әрбір аппараттық платформа үшін бір deb бумасы жеткілікті.
Бірақ rpm пакеттері әлемінде айырмашылықтар үлкен. Біріншіден, екі толық тәуелсіз дистрибьютор бар болғандықтан, Red Hat және SUSE, олар үшін үйлесімділік мүлдем қажет емес. Екіншіден, бұл дистрибьюторларда олардың тарату жинақтары бар. қолдау және эксперименттік. Олардың арасында үйлесімділіктің де қажеті жоқ. El6, el7 және el8 өз пакеттері бар екені белгілі болды. Fedora үшін бөлек пакет. SLES11 және 12 пакеттері және openSUSE үшін бөлек. Негізгі мәселе - тәуелділіктер мен бума атаулары.
Тәуелділік мәселесі
Өкінішке орай, бірдей пакеттер жиі әртүрлі дистрибутивтерде әртүрлі атаулармен аяқталады. Төменде veeam бумасы тәуелділіктерінің ішінара тізімі берілген.
EL7 үшін:
SLES 12 үшін:
- libblkid
- libgcc
- libstdc++
- ncurses-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 дистрибьюторы шешуге тырысатын тапсырма.
Пакет менеджері бұл мәселені мүлдем басқа жолмен шешуге тырысады. Snappy Canonical компаниясынан. Негізгі идея: қолданба негізгі жүйеден оқшауланған және қорғалған құм жәшігінде жұмыс істейді. Егер қолданба кітапханаларды қажет етсе, олар қолданбаның өзімен бірге жеткізіледі.
Тегістеуіш сонымен қатар Linux контейнерлерін пайдаланып қолданбаларды құм жәшігінде іске қосуға мүмкіндік береді. Құм жәшік идеясы да пайдаланылады AppImage.
Бұл шешімдер кез келген тарату үшін бір буманы жасауға мүмкіндік береді. болған жағдайда Тегістеуіш қолданбаны орнату және іске қосу әкімшінің хабарынсыз да мүмкін.
Негізгі мәселе - барлық қолданбалар құм жәшігінде жұмыс істей алмайды. Кейбір адамдарға платформаға тікелей кіру қажет. Мен тіпті ядроға қатаң тәуелді және құмсалғыш тұжырымдамасына сәйкес келмейтін ядро модульдері туралы айтпаймын.
Екінші мәселе - Red Hat және SUSE-дан кәсіпорын ортасында танымал дистрибутивтерде әлі Snappy және Flatpak қолдауы жоқ.
Осыған байланысты Veeam Agent for Linux қолжетімді емес ештене етпейді .
Пакет менеджерлері туралы сұрақты аяқтау үшін екілік файлдарды және оларды бір бумаға орнату сценарийін біріктіру арқылы пакет менеджерлерінен мүлдем бас тарту мүмкіндігі бар екенін атап өткім келеді.
Мұндай топтама әртүрлі дистрибутивтер мен платформалар үшін бір жалпы пакетті жасауға, қажетті теңшеуді жүзеге асыра отырып, интерактивті орнату процесін жүзеге асыруға мүмкіндік береді. Мен Linux үшін мұндай пакеттерді VMware жүйесінен ғана кездестірдім.
Жаңарту мәселесі
Барлық тәуелділік мәселелері шешілсе де, бағдарлама бірдей таратуда басқаша жұмыс істеуі мүмкін. Бұл жаңартулар мәселесі.
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 пакеттері осылай құрастырылады.
Құрастыру қызметін ашыңыз
SUSE әріптестері қосымшаларды құрастыруға және пакеттерді жинауға арналған арнайы қызмет түріндегі кейбір ортаны енгізуге тырысты - .
Негізінде, бұл виртуалды машинаны жасайтын, оған барлық қажетті пакеттерді орнататын, қосымшаны құрастыратын және осы оқшауланған ортада буманы құрастыратын, содан кейін виртуалды машина шығарылатын гипервизор.
OpenBuildService бағдарламасында енгізілген жоспарлаушы пакетті құрудың оңтайлы жылдамдығы үшін қанша виртуалды машинаны іске қоса алатынын анықтайды. Кірістірілген қол қою механизмі пакеттерге қол қояды және оларды кірістірілген репозиторийге жүктеп салады. Кірістірілген нұсқаны басқару жүйесі өзгерістер мен құрастыру тарихын сақтайды. Бұл жүйеге көздеріңізді қосу ғана қалады. Серверді өзіңіз орнатудың қажеті жоқ; сіз ашық серверді пайдалана аласыз.
Дегенмен, бір мәселе бар: мұндай комбайнды қолданыстағы инфрақұрылымға сыйғызу қиын. Мысалы, нұсқаны басқару қажет емес, бізде бастапқы кодтар үшін өзіміздің жеке кодтарымыз бар. Біздің қолтаңба механизміміз әртүрлі: біз арнайы серверді қолданамыз. Репозиторий де қажет емес.
Сонымен қатар, басқа дистрибутивтерге қолдау көрсету - мысалы, Red Hat - өте нашар жүзеге асырылады, бұл түсінікті.
Мұндай қызметтің артықшылығы - SUSE таратуының келесі нұсқасына жылдам қолдау көрсету. Шығарылым туралы ресми хабарландырудың алдында құрастыруға қажетті пакеттер жалпыға қолжетімді репозиторийде орналастырылады. Жаңасы OpenBuildService қызметіндегі қолжетімді таратулар тізімінде пайда болады. Біз құсбелгіні қоямыз және ол құрылыс жоспарына қосылады. Осылайша, таратудың жаңа нұсқасын қосу бір рет басу арқылы жүзеге асырылады.
Біздің инфрақұрылымымызда OpenBuildService көмегімен SUSE дистрибутивтеріне арналған veeamsnap ядро модулінің KMP пакеттерінің барлық түрі жинақталған.
Әрі қарай, ядро модульдеріне тән мәселелерге тоқталғым келеді.
ABI ядросы
Linux ядросының модульдері тарихи түрде бастапқы пішінде таратылды. Өйткені, ядроны жасаушылар ядро модульдері үшін тұрақты 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 үйлесімділігі мен ядроның тұрақтылығын қамтамасыз етуге тырысса да, олар өнімділікті жақсартуға және осы тұрақты ядроның ақауларын жоюға тырысады.
Сонымен қатар, өздерінің «қателермен жұмыс істеуінен» басқа, 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 ядросының блок енгізу/шығару 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 дистрибутивтері жүйеде сәйкес сертификат тіркелген жағдайда ғана модульдің қолтаңбасын тексеруге және оны жүктеуге мүмкіндік береді. Сертификат модульге қол қойылған ашық кілт болып табылады. Біз оны бөлек пакет ретінде таратамыз.
Мәселе мынада, сертификаттар ядроға салынуы мүмкін (дистрибьюторлар оларды пайдаланады) немесе утилита арқылы EFI тұрақты жадына жазылуы керек. мокутил. Утилита мокутил Куәлікті орнату кезінде ол жүйені қайта жүктеуді талап етеді және тіпті операциялық жүйенің ядросын жүктемес бұрын әкімшіден жаңа куәлікті жүктеуге рұқсат беруді сұрайды.
Осылайша, сертификат қосу жүйеге физикалық әкімшінің рұқсатын талап етеді. Егер құрылғы бұлттың бір жерінде немесе жай ғана қашықтағы сервер бөлмесінде орналасса және кіру тек желі арқылы болса (мысалы, 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 нұсқасы үшін ресми түрде қолдау көрсетілетін дистрибутивтердің ағымдағы тізімін зерттеуге болады . Бірақ біздің өнім жұмыс істей алатын дистрибуциялардың нақты тізімі әлдеқайда кең.
Жеке мені Эльбрус ОЖ-мен эксперимент қызықтырды. veeam бумасын аяқтағаннан кейін өніміміз орнатылып, жұмыс істеді. Мен бұл эксперимент туралы Хабреде жаздым .
Жаңа дистрибуцияларды қолдау жалғасуда. Біз 4.0 нұсқасының шығуын күтеміз. Бета пайда болғалы тұр, сондықтан абай болыңыз !
Ақпарат көзі: www.habr.com