Ямар ч түгээлт дээр ажиллах нөөц програм үүсгэх нь тийм ч амар ажил биш юм. Linux-д зориулсан Veeam Agent нь Red Hat 6, Debian 6, OpenSUSE 15.1 болон Ubuntu 19.04 хүртэлх түгээлтүүд дээр ажиллахын тулд, ялангуяа програм хангамжийн бүтээгдэхүүнд цөмийн модуль агуулагдаж байгаа тул олон асуудлыг шийдэх хэрэгтэй.
Уг нийтлэлийг хурал дээр хэлсэн үгийн материалд үндэслэн бүтээв .
Линукс бол хамгийн алдартай үйлдлийн системүүдийн нэг биш юм. Үндсэндээ энэ бол та өөрийн гэсэн өвөрмөц зүйлийг хийх боломжтой платформ юм. Үүний ачаар Линукс нь програм хангамжийн бүрэлдэхүүн хэсгүүдээрээ ялгаатай олон түгээлттэй байдаг. Энд нэг асуудал гарч ирдэг: програм хангамжийн бүтээгдэхүүн нь ямар ч түгээлт дээр ажиллахын тулд та тус бүрийн онцлогийг харгалзан үзэх хэрэгтэй.
Багц менежерүүд. .deb vs .rpm
Бүтээгдэхүүнийг янз бүрийн хуваарилалтаар түгээх тодорхой асуудлаас эхэлье.
Програм хангамжийн бүтээгдэхүүнийг түгээх хамгийн түгээмэл арга бол багцыг репозитор дээр байрлуулах бөгөөд системд суулгасан багц менежер үүнийг тэндээс суулгаж болно.
Гэсэн хэдий ч бидэнд хоёр алдартай багц формат байдаг: мин и deb. Энэ нь хүн бүр дэмжих ёстой гэсэн үг юм.
Деб багцуудын ертөнцөд нийцтэй байдлын түвшин гайхалтай юм. Ижил багц нь 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
- гал хамгаалагч
- файлын сангууд
- veeamsnap=3.0.2.1185
- libblkid1
- libgcc_s1
- libstdc++6
- libmagic1
- libfuse2
- veeamsnap-kmp=3.0.2.1185
Үүний үр дүнд хамаарлын жагсаалт нь түгээлтийн хувьд өвөрмөц юм.
Хамгийн муу зүйл бол шинэчилсэн хувилбар нь хуучин багцын нэр дор нуугдаж эхлэх явдал юм.
Жишээ нь:
Багцыг Fedora 24 дээр шинэчилсэн nursurs 5-аас 6-р хувилбар хүртэл. Манай бүтээгдэхүүнийг хуучин түгээлтүүдтэй нийцүүлэхийн тулд 5-р хувилбараар бүтээсэн. Fedora 5 дээрх номын сангийн хуучин 24-р хувилбарыг ашиглахын тулд би багцыг ашиглах шаардлагатай болсон ncurses-compat-libs.
Үүний үр дүнд Fedora-д зориулж өөр өөр хамааралтай хоёр багц байдаг.
Цаашид илүү сонирхолтой. Дараагийн түгээлтийн шинэчлэлтийн дараа багц ncurses-compat-libs номын сангийн 5-р хувилбарын хувьд энэ нь боломжгүй болсон. Хуучин номын сангуудыг түгээлтийн шинэ хувилбар руу чирэх нь дистрибьютерийн хувьд үнэтэй байдаг. Хэсэг хугацааны дараа асуудал SUSE түгээлтэд давтагдсан.
Үүний үр дүнд зарим түгээлтүүд тодорхой хамаарлаа орхих шаардлагатай болсон ncurses-libs, мөн номын сангийн аль ч хувилбартай ажиллах боломжтой байхаар бүтээгдэхүүнийг засаарай.
Дашрамд хэлэхэд, Red Hat-ийн 8-р хувилбарт мета багц байхгүй болсон Python, энэ нь сайн хуучны тухай өгүүлдэг питон 2.7Байна. байдаг python2 и Python3.
Багц менежерүүдийн альтернатив хувилбар
Хамааралтай холбоотой асуудал хуучирсан бөгөөд эрт дээр үеэс тодорхой болсон. Зөвхөн хараат байдлын тамыг санаарай.
Төрөл бүрийн номын сан, програмуудыг нэгтгэхийн тулд тэдгээр нь бүгд тогтвортой ажиллаж, зөрчилдөхгүй байх нь үнэн хэрэгтээ энэ нь аливаа Линукс дистрибьютерийн шийдэхийг хичээдэг ажил юм.
Багц менежер энэ асуудлыг огт өөр аргаар шийдэхийг оролддог. Сэлбэ Canonical-аас. Гол санаа: програм нь үндсэн системээс тусгаарлагдсан, хамгаалагдсан хамгаалагдсан хязгаарлагдмал орчинд ажилладаг. Хэрэв програмд номын сан шаардлагатай бол тэдгээрийг програмын хамт нийлүүлнэ.
Flatpak Мөн Linux Containers ашиглан хамгаалагдсан хязгаарлагдмал орчинд програмуудыг ажиллуулах боломжийг танд олгоно. Мөн хамгаалагдсан хязгаарлагдмал орчны санааг ашигладаг AppImage.
Эдгээр шийдлүүд нь ямар ч түгээлтэд зориулж нэг багц үүсгэх боломжийг олгодог. Тохиолдолд Flatpak Програмыг суулгах, эхлүүлэх нь администраторын мэдэгдэлгүйгээр ч боломжтой.
Хамгийн гол асуудал бол бүх програмууд хамгаалагдсан хязгаарлагдмал орчинд ажиллах боломжгүй юм. Зарим хүмүүс платформ руу шууд нэвтрэх шаардлагатай болдог. Цөмөөс хатуу хамааралтай, хамгаалагдсан хязгаарлагдмал орчинд тохирохгүй цөмийн модулиудын талаар ч би яриагүй байна.
Хоёрдахь асуудал бол Red Hat болон SUSE-ийн байгууллагын орчинд түгээмэл тархсан түгээлтүүд нь Snappy болон Flatpak-ийн дэмжлэгийг хараахан агуулаагүй байгаа явдал юм.
Үүнтэй холбогдуулан Linux-д зориулсан Veeam Agent байхгүй байна огтхон ч биш .
Багц менежерүүдийн талаархи асуултыг дуусгахын тулд хоёртын файлууд болон тэдгээрийг нэг багцад суулгах скриптийг нэгтгэх замаар багц менежерүүдээс бүрмөсөн татгалзах сонголт байгааг тэмдэглэхийг хүсч байна.
Ийм багц нь янз бүрийн түгээлт, платформд зориулсан нэг нийтлэг багц үүсгэх, интерактив суулгах процессыг гүйцэтгэх, шаардлагатай тохиргоог хийх боломжийг олгодог. Би зөвхөн VMware-аас Linux-д зориулсан ийм багцуудтай тааралдсан.
Шинэчлэлтийн асуудал
Хамааралтай холбоотой бүх асуудал шийдэгдсэн ч гэсэн програм нь ижил хуваарилалт дээр өөр өөр ажиллаж болно. Энэ нь шинэчлэлтүүдийн тухай юм.
Шинэчлэх 3 стратеги байдаг:
- Хамгийн энгийн нь хэзээ ч шинэчлэхгүй байх явдал юм. Би серверээ тавиад мартчихаж. Хэрэв бүх зүйл ажиллаж байвал яагаад шинэчлэх вэ? Анх удаа тусламж үйлчилгээтэй холбоо барихад асуудал гарч эхэлдэг. Түгээлтийн бүтээгч нь зөвхөн шинэчилсэн хувилбарыг дэмждэг.
- Та дистрибьютерт итгэж, автомат шинэчлэлтүүдийг тохируулах боломжтой. Энэ тохиолдолд шинэчлэлт амжилтгүй болсны дараа шууд дэмжлэг үзүүлэх дуудлага ирэх магадлалтай.
- Туршилтын дэд бүтэц дээр ажиллуулсны дараа л гараар шинэчлэх сонголт нь хамгийн найдвартай боловч үнэтэй бөгөөд цаг хугацаа их шаарддаг. Хүн бүр үүнийг төлж чадахгүй.
Өөр өөр хэрэглэгчид өөр өөр шинэчлэлтийн стратеги ашигладаг тул хамгийн сүүлийн хувилбар болон өмнө нь гаргасан бүх хувилбарыг хоёуланг нь дэмжих шаардлагатай. Энэ нь хөгжүүлэлт, туршилтын үйл явцыг хоёуланг нь хүндрүүлж, дэмжлэг үзүүлэх багт толгой өвдөхөд хүргэдэг.
Төрөл бүрийн техник хангамжийн платформууд
Төрөл бүрийн техник хангамжийн платформууд нь үндсэн кодтой холбоотой асуудал юм. Хамгийн багадаа дэмжигдсэн платформ бүрийн хувьд хоёртын файлуудыг цуглуулах хэрэгтэй.
Linux-д зориулсан Veeam Agent төслийн хувьд бид RISC шиг ямар ч зүйлийг дэмжих боломжгүй хэвээр байна.
Би энэ асуудлын талаар дэлгэрэнгүй ярихгүй. Би зөвхөн үндсэн асуудлуудыг тоймлох болно: платформоос хамааралтай төрлүүд, жишээлбэл size_t, бүтцийн зэрэглэл болон байт дараалал.
Статик ба/эсвэл динамик холболт
Гэхдээ асуулт бол "Номын сангуудтай динамик эсвэл статик байдлаар хэрхэн холбогдох вэ?" хэлэлцэх нь зүйтэй.
Дүрмээр бол Линукс дээрх 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-ийн тохиромжтой хувилбарыг сонгох эсвэл бүтээх, тодорхой архитектурт зориулсан хөндлөн хөрвүүлэгч ашиглах, бүхэл бүтэн номын сангуудыг цуглуулахад хангалттай. Энэ ажил нэлээд боломжтой, гэхдээ нэлээд төвөгтэй ажил юм. Сонгосон хөрвүүлэгч болон номын сангууд ажиллах боломжтой хувилбарыг өгөх баталгаа байхгүй.
Мэдээжийн давуу тал нь: нэг машин дээр бүхэл бүтэн барилгын үйл явцыг дуусгах боломжтой тул дэд бүтцийг маш хялбаршуулсан. Нэмж дурдахад нэг архитектурт зориулж нэг багц хоёртын файлуудыг цуглуулахад хангалттай бөгөөд та тэдгээрийг өөр өөр түгээлтийн багц болгон багцалж болно. Linux-д зориулсан Veeam Agent-д зориулж veeam багцуудыг ингэж бүтээдэг.
Энэ сонголтоос ялгаатай нь та зүгээр л барих ферм, өөрөөр хэлбэл угсрах хэд хэдэн машин бэлтгэх боломжтой. Ийм машин бүр тодорхой хуваарилалт, тодорхой архитектурт зориулсан програмын эмхэтгэл, багц угсралтыг хангана. Энэ тохиолдолд эмхэтгэлийг дистрибьютерийн бэлтгэсэн хэрэгслийг ашиглан гүйцэтгэдэг. Өөрөөр хэлбэл эмхэтгэгч бэлтгэх, номын санг сонгох үе шат алга болно. Үүнээс гадна, угсралтын процессыг хялбархан зэрэгцүүлж болно.
Гэсэн хэдий ч энэ аргын сул тал бий: ижил архитектур доторх тархалт бүрийн хувьд та өөрийн хоёртын файлуудыг цуглуулах хэрэгтэй болно. Өөр нэг сул тал нь ийм олон тооны машиныг засвар үйлчилгээ хийх шаардлагатай бөгөөд их хэмжээний дискний зай, RAM-ыг хуваарилах шаардлагатай болдог.
Red Hat түгээлтийн хувьд veeamsnap цөмийн модулийн KMOD багцуудыг ингэж эмхэтгэсэн.
Бүтээлийн үйлчилгээг нээнэ үү
SUSE-ийн хамт олон програмуудыг эмхэтгэх, багцуудыг угсрах тусгай үйлчилгээ хэлбэрээр зарим нэг дунд хэсгийг хэрэгжүүлэхийг оролдсон - .
Үндсэндээ энэ нь виртуал машин үүсгэж, түүнд шаардлагатай бүх багцуудыг суулгаж, програмыг эмхэтгэж, багцыг энэхүү тусгаарлагдсан орчинд бүтээж, дараа нь виртуал машиныг гаргадаг гипервизор юм.
OpenBuildService-д хэрэгжсэн хуваарьлагч нь багц бүтээх оновчтой хурдыг авахын тулд хэдэн виртуал машин ажиллуулж болохыг тодорхойлох болно. Баригдсан гарын үсэг зурах механизм нь багцуудад гарын үсэг зурж, тэдгээрийг суулгасан репозитор руу байршуулах болно. Суурилуулсан хувилбарын хяналтын систем нь өөрчлөлт, бүтээцийн түүхийг хадгалах болно. Энэ системд эх сурвалжаа нэмэх л үлдлээ. Та серверээ өөрөө тохируулах шаардлагагүй, нээлттэй серверийг ашиглаж болно.
Гэсэн хэдий ч нэг асуудал бий: ийм комбайныг одоо байгаа дэд бүтцэд оруулахад хэцүү байдаг. Жишээлбэл, хувилбарын хяналт шаардлагагүй, бид аль хэдийн өөрийн эх кодтой болсон. Бидний гарын үсгийн механизм өөр: бид тусгай сервер ашигладаг. Хадгалах газар бас шаардлагагүй.
Нэмж дурдахад бусад түгээлтийн дэмжлэг, жишээлбэл, Red Hat гэх мэт маш муу хэрэгжсэн нь ойлгомжтой.
Ийм үйлчилгээний давуу тал нь SUSE түгээлтийн дараагийн хувилбарт хурдан дэмжлэг үзүүлэх явдал юм. Хувилбарыг албан ёсоор зарлахаас өмнө угсрахад шаардлагатай багцуудыг олон нийтийн мэдээллийн санд байрлуулсан болно. OpenBuildService дээрх боломжтой түгээлтийн жагсаалтад шинээр гарч ирнэ. Бид хайрцгийг шалгаад барилгын төлөвлөгөөнд нэмж оруулав. Тиймээс түгээлтийн шинэ хувилбарыг нэмэх нь бараг нэг товшилтоор хийгддэг.
Манай дэд бүтцэд OpenBuildService ашиглан SUSE түгээлтийн veeamsnap цөмийн модулийн бүх төрлийн KMP багцуудыг угсардаг.
Дараа нь би цөмийн модулиудтай холбоотой асуудлуудад анхаарлаа хандуулахыг хүсч байна.
цөмийн ABI
Линуксийн цөмийн модулиуд нь түүхийн хувьд эх хэлбэрээр тархсан байдаг. Баримт нь цөм бүтээгчид цөмийн модулиудын тогтвортой 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 оны XNUMX-р сард гарсан) хувилбар дээр ажиллах ёстой. Тэгээд бараг XNUMX жил болж байна. Мэдээжийн хэрэг, энэ даалгавар нэлээд хэцүү байдаг.
kABI нийцтэй байдлын асуудлаас болж veeamsnap модуль ажиллахаа больсон хэд хэдэн тохиолдлыг бид бүртгэсэн.
RHEL 7.0-д зориулан эмхэтгэсэн veeamsnap модуль нь RHEL 7.5-ын цөмтэй тохирохгүй болсон боловч ачаалагдсан бөгөөд серверийг сүйрүүлэх баталгаатай болсон тул бид RHEL 7-д зориулсан kABI нийцтэй байдлын хэрэглээг бүрмөсөн орхисон.
Одоогоор RHEL 7-д зориулсан KMOD багц нь хувилбар бүрийн угсралт болон модулийг ачаалах скриптийг агуулж байна.
SUSE нь kABI нийцтэй байдлын ажилд илүү анхааралтай хандсан. Тэд зөвхөн нэг үйлчилгээний багц дотор kABI нийцтэй байдлыг хангадаг.
Жишээлбэл, SLES 12 хувилбар 2014 оны 12-р сард гарсан. SLES 1 SP2015 нь 3.12 оны XNUMX-р сард аль хэдийн гарсан, өөрөөр хэлбэл жил гаруйн хугацаа өнгөрсөн байна. Хэдийгээр хоёр хувилбар нь XNUMX цөмийг ашигладаг ч kABI-тай нийцэхгүй байна. Мэдээжийн хэрэг, kABI-ийн нийцтэй байдлыг нэг жилийн хугацаанд хадгалах нь илүү хялбар байдаг. Жилийн цөмийн модулийн шинэчлэлтийн мөчлөг нь модуль бүтээгчдэд асуудал үүсгэх ёсгүй.
Энэхүү SUSE бодлогын үр дүнд бид veeamsnap модульд kABI нийцтэй холбоотой нэг ч асуудал бүртгэгдээгүй байна. Үнэн, SUSE-д зориулсан багцын тоо бараг л илүү том захиалга юм.
Засварууд болон арын портууд
Хэдийгээр дистрибьюторууд kABI-ийн нийцтэй байдал, цөмийн тогтвортой байдлыг хангахыг хичээдэг ч гүйцэтгэлийг сайжруулж, энэхүү тогтвортой цөмийн согогийг арилгахыг хичээдэг.
Үүний зэрэгцээ, өөрсдийн "алдаа дээр ажиллах" -аас гадна Linux цөмийг хөгжүүлэгчид ванилийн цөм дэх өөрчлөлтийг хянаж, "тогтвортой" руу шилжүүлдэг.
Заримдаа энэ нь шинэ зүйлд хүргэдэг .
Red Hat 6-ийн хамгийн сүүлийн хувилбарт бага зэргийн шинэчлэлтүүдийн нэгэнд алдаа гарсан. Энэ нь хормын хувилбарыг гаргахад veeamsnap модуль нь системийг сүйрүүлэх баталгаатай болсон. Шинэчлэлт хийхээс өмнө болон дараа нь цөмийн эх сурвалжуудыг харьцуулж үзээд бид арын порт буруутай болохыг олж мэдсэн. Үүнтэй төстэй засварыг ванилийн цөмийн 4.19 хувилбар дээр хийсэн. Зүгээр л энэ засвар ванилийн цөмд сайн ажилласан боловч үүнийг "тогтвортой" 2.6.32 руу шилжүүлэх үед spinlock дээр асуудал үүссэн.
Мэдээжийн хэрэг, хүн бүр үргэлж алдаатай байдаг, гэхдээ тогтвортой байдлыг эрсдэлд оруулж, 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 түгээлтүүд нь модулийн гарын үсгийг шалгаж, холбогдох гэрчилгээг системд бүртгүүлсэн тохиолдолд л ачаалах боломжийг олгодог. Сертификат нь модульд гарын үсэг зурсан нийтийн түлхүүр юм. Бид үүнийг тусдаа багц болгон тараадаг.
Энд байгаа асуудал бол гэрчилгээг цөмд суулгаж болно (дистрибьюторууд үүнийг ашигладаг) эсвэл хэрэгсэл ашиглан EFI тогтворгүй санах ойд бичих ёстой. мокутил. Хэрэгсэл мокутил Сертификат суулгах үед энэ нь таныг системийг дахин ачаалахыг шаарддаг бөгөөд үйлдлийн системийн цөмийг ачаалахаас өмнө админаас шинэ гэрчилгээг ачаалахыг зөвшөөрөхийг сануулдаг.
Тиймээс гэрчилгээ нэмэхийн тулд системд администратор хандах шаардлагатай. Хэрэв машин нь үүлэн дотор хаа нэгтээ эсвэл зүгээр л алсын серверийн өрөөнд байрладаг бөгөөд нэвтрэх нь зөвхөн сүлжээгээр (жишээлбэл, ssh-ээр) байвал гэрчилгээ нэмэх боломжгүй болно.
Виртуал машин дээрх EFI
EFI-г бараг бүх эх хавтангийн үйлдвэрлэгчид удаан хугацаанд дэмжиж ирсэн хэдий ч системийг суулгахдаа администратор EFI-ийн хэрэгцээний талаар бодохгүй байж магадгүй бөгөөд үүнийг идэвхгүй болгож магадгүй юм.
Бүх гипервизорууд EFI-г дэмждэггүй. VMWare vSphere нь 5-р хувилбараас эхлэн EFI-г дэмждэг.
Microsoft Hyper-V нь Windows Server 2012R2-д зориулсан Hyper-V-ээс эхлэн EFI-ийн дэмжлэгийг авсан.
Гэсэн хэдий ч анхдагч тохиргоонд энэ функцийг Линукс машинуудад идэвхгүй болгосон бөгөөд энэ нь гэрчилгээг суулгах боломжгүй гэсэн үг юм.
vSphere 6.5 дээр сонголтыг тохируулна уу Аюулгүй Ачаалагч зөвхөн Flash-ээр ажилладаг вэб интерфэйсийн хуучин хувилбарт л боломжтой. HTML-5 дээрх вэб UI хол хоцорсон хэвээр байна.
Туршилтын хуваарилалт
Эцэст нь, албан ёсны дэмжлэггүйгээр туршилтын хуваарилалт, түгээлтийн асуудлыг авч үзье. Нэг талаас, ийм хуваарилалт нь ноцтой байгууллагуудын сервер дээр олдохгүй байх магадлалтай. Ийм хуваарилалтад албан ёсны дэмжлэг байдаггүй. Тиймээс тэдгээрийг хангана уу. Бүтээгдэхүүнийг ийм түгээлт дээр дэмжих боломжгүй.
Гэсэн хэдий ч ийм хуваарилалт нь шинэ туршилтын шийдлүүдийг туршиж үзэхэд тохиромжтой платформ болдог. Жишээлбэл, Fedora, OpenSUSE Tumbleweed эсвэл Debian-ийн тогтворгүй хувилбарууд. Тэд нэлээд тогтвортой байдаг. Тэд үргэлж програмын шинэ хувилбар, үргэлж шинэ цөмтэй байдаг. Жилийн дараа энэхүү туршилтын функц нь шинэчлэгдсэн RHEL, SLES эсвэл Ubuntu дээр дуусч магадгүй юм.
Хэрэв туршилтын хуваарилалт дээр ямар нэг зүйл ажиллахгүй бол энэ нь асуудлыг тодорхойлж, шийдвэрлэх шалтгаан болно. Энэ функц удахгүй хэрэглэгчдийн үйлдвэрлэлийн сервер дээр гарч ирэх болно гэдэгт та бэлтгэлтэй байх хэрэгтэй.
Та 3.0 хувилбарын албан ёсоор дэмжигдсэн түгээлтийн одоогийн жагсаалтыг судалж болно . Гэхдээ манай бүтээгдэхүүн дээр ажиллах боломжтой түгээлтийн бодит жагсаалт илүү өргөн байна.
Би хувьдаа Elbrus OS-ийн туршилтыг сонирхож байсан. Veeam багцыг дуусгасны дараа манай бүтээгдэхүүнийг суурилуулж, ажиллаж байна. Би энэ туршилтын талаар Хабре дээр бичсэн .
За, шинэ түгээлтийн дэмжлэг үргэлжилсээр байна. Бид 4.0 хувилбар гарахыг хүлээж байна. Бета гарах гэж байгаа тул анхаарал болгоомжтой байгаарай !
Эх сурвалж: www.habr.com