Veb-server qanday ishlaydi. Ma'lumotlar bazasi xizmati serveri

Server uskunalari bilan bir qatorda har qanday uskunalar ba'zan kutilmagan tarzda ishlay boshlaydi. Ushbu uskunaning yangi bo'ladimi yoki bir necha yildan beri to'liq yuk bilan ishlayaptimi, umuman farqi yo'q.

Nosozlik va noto'g'ri ishlashning ko'plab holatlari mavjud va muammoni tashxislash ko'pincha jumboqli jumboqga aylanadi.

Quyida biz qiziqarli va ahamiyatsiz bo'lmagan holatlar haqida gaplashamiz.

Muammolarni topish

Muammolarni ro'yxatdan o'tkazish ko'pincha mijozlar chipta tizimi orqali texnik qo'llab-quvvatlash xizmatiga murojaat qilganidan keyin paydo bo'ladi.

Bizdan belgilangan konfiguratsiyaga bag'ishlangan serverlarni ijaraga oladigan mijoz so'rov yuborgan taqdirda, biz muammo dasturiy ta'minotga tegishli emasligini aniqlash uchun diagnostika o'tkazamiz.

Mijozlar odatda dasturiy ta'minot bilan bog'liq muammolarni o'zlari hal qilishadi, shunga qaramay, biz har qanday holatda ham tizim ma'murlarimizning yordamini taklif qilamiz.

Agar muammo apparat ekanligi ayon bo'lsa (masalan, server RAMning bir qismini ko'rmaydi), unda bu holda biz doimo shu kabi server platformasini zaxirada saqlaymiz.

Agar apparat muammosi aniqlansa, biz disklarni ishlamay qolgan serverdan zaxira nusxasiga o'tkazamiz va tarmoq uskunasining kichik qayta konfiguratsiyasidan so'ng server ishga tushadi. Shunday qilib, ma'lumotlar yo'qolmaydi va ishlamay qolish vaqti kirish paytidan boshlab 20 daqiqadan oshmaydi.

Muammolarga misollar va ularni qanday tuzatish kerak

Serverda tarmoq ishlamay qoldi

Disklarni ishlamay qolgan serverdan zaxira nusxasiga o'tkazgandan so'ng, serverdagi tarmoq ishlamay qolishi ehtimoli mavjud. Bu odatda Debian yoki Ubuntu kabi Linux operatsion tizimlarida sodir bo'ladi.

Haqiqat shundaki, operatsion tizimni dastlabki o'rnatishda tarmoq kartalarining MAC manzillari quyidagi manzilda joylashgan maxsus faylga yoziladi: /etc/udev/rules.d/70-persistent-net.rules.

Operatsion tizim ishga tushganda, ushbu fayl interfeys nomlarini MAC manzillariga moslashtiradi. Serverni zaxira nusxasi bilan almashtirganda, tarmoq interfeyslarining MAC manzillari endi mos kelmaydi, bu esa serverdagi tarmoqning ishlamasligiga olib keladi.

Muammoni hal qilish uchun siz ko'rsatilgan faylni o'chirib tashlashingiz va tarmoq xizmatini qayta yoqishingiz yoki serverni qayta yoqishingiz kerak.

Ushbu faylni topmagan operatsion tizim avtomatik ravishda shunga o'xshash faylni yaratadi va interfeyslarni tarmoq kartalarining yangi MAC manzillariga moslashtiradi.

Shundan so'ng IP-manzillarni qayta sozlashning hojati yo'q, tarmoq darhol ishlay boshlaydi.

Muzlatish muammosi

Bir marta biz ish paytida tasodifiy muzlash muammosi bilan diagnostika qilish uchun server oldik. Biz BIOS va IPMI jurnallarini tekshirdik - bo'sh, xatolar yo'q. Biz uni stressni sinashga qo'ydik, barcha protsessor yadrolarini 100% yukladik, bir vaqtning o'zida haroratni boshqarish bilan - u 30 daqiqalik ishdan keyin qattiq muzlab qoldi.

Shu bilan birga, protsessor normal ishladi, haroratlar yuk ostida standartlardan oshmadi, barcha sovutgichlar yaxshi ishladi. Muammoning qizib ketmasligi aniq bo'ldi.

Bundan tashqari, RAM modullarining mumkin bo'lgan nosozliklarini istisno qilish kerak edi, shuning uchun biz juda mashhur Memtest86 + yordamida serverni xotira testiga qo'ydik. Taxminan 20 daqiqadan so'ng, server kutilganidek qotib qoldi va RAM modullaridan birida xatolarga yo'l qo'ydi.

Modulni yangisiga almashtirib, biz yana serverni sinovga qo'ydik, ammo biz fiyaskoga duch keldik - server boshqa RAM moduli uchun xatolar keltirib, yana o'chib qoldi. Ular ham uning o'rnini egallashdi. Yana bir sinov - yana bir marta telefonni o'chirib qo'ydi va yana RAM-da xatolarga yo'l qo'ydi. RAM uyalarini sinchkovlik bilan tekshirishda nuqsonlar aniqlanmadi.

Muammoni hal qilishda mumkin bo'lgan bitta aybdor qoldi - markaziy protsessor. Haqiqat shundaki, RAM boshqaruvchisi aynan protsessor ichida joylashgan va u muvaffaqiyatsiz bo'lishi mumkin edi.

Protsessorni olib tashlaganimizdan so'ng, biz falokatni topdik - rozetkaning bitta pimi yuqori qismida sindirilgan, pinning singan uchi so'zma-so'z protsessorning aloqa maydoniga yopishgan. Natijada, serverda yuk bo'lmaganda, hamma narsa etarli darajada ishladi, ammo protsessor harorati ko'tarilganda, aloqa uzilib qoldi va shu bilan RAM boshqaruvchisining normal ishlashini to'xtatdi, bu esa muzlashni keltirib chiqardi.

Va nihoyat, muammo anakartni almashtirish bilan hal qilindi, chunki afsuski, biz singan rozetkaning pimini tiklay olmaymiz va bu allaqachon xizmat ko'rsatish markazining vazifasi.

OSni o'rnatish paytida ko'rinadigan server osib qo'yiladi

Uskuna ishlab chiqaruvchilari eski texnologiyalarni qo'llab-quvvatlashdan voz kechib, yangilarining foydasiga apparat me'morchiligini o'zgartira boshlaganda juda kulgili holatlar paydo bo'ladi.

Bir foydalanuvchi Windows Server 2008 R2 operatsion tizimini o'rnatishda serverning muzlashi haqida shikoyat bilan bizga murojaat qildi. O'rnatishni muvaffaqiyatli ishga tushirgandan so'ng, server KVM konsolidagi sichqoncha va klaviaturaga javob berishni to'xtatdi. Muammoni lokalizatsiya qilish uchun biz serverga jismoniy sichqoncha va klaviaturani uladik - barchasi bir xil, o'rnatuvchi kirish moslamalariga javob berishni boshlaydi va to'xtatadi.

O'sha paytda ushbu server Supermicro tomonidan ishlab chiqarilgan X11SSL-f anakart asosida birinchilardan biri bo'lgan. BIOS sozlamalarida "O'chirish" ga o'rnatilgan bitta qiziqarli Windows 7 o'rnatish elementi mavjud edi. Windows 7, 2008 va 2008 R2 bir xil o'rnatuvchida joylashganligi sababli biz ushbu parametrni Enable-ga o'rnatdik va mo''jizaviy ravishda sichqoncha va klaviatura ishladi. Ammo bu operatsion tizim o'rnatilishi bilan eposning faqat boshlanishi edi.

O'rnatish uchun diskni tanlash paytida hech qanday disk ko'rsatilmadi, shuningdek, qo'shimcha drayverlarni o'rnatishni talab qiladigan xatolik yuz berdi. Operatsion tizim USB-stikdan o'rnatildi va Internetda tezkor qidiruv shuni ko'rsatdiki, ushbu effekt o'rnatuvchi USB 3.0 tekshiruvi uchun drayverni topa olmaganida sodir bo'ladi.

Vikipediya, BIOS-da USB 3.0 (XHCI tekshiruvi) yordamini o'chirib qo'yish bilan muammo hal qilinganligini xabar qildi. Anakart uchun hujjatlarni ochganimizda, bizni kutilmagan voqea kutib turdi - ishlab chiquvchilar EHCI (Enhanced Host Controller Interface) boshqaruvidan XHCI (eXtensible Host Controller Interface) foydasiga butunlay voz kechishga qaror qilishdi. Boshqacha qilib aytganda, ushbu anakartdagi barcha USB portlar USB 3.0 portlaridir. Va agar siz XHCI tekshirgichini o'chirib qo'ysangiz, unda biz kirish moslamalarini o'chirib qo'yamiz, shuning uchun server bilan ishlashni va shunga mos ravishda operatsion tizimni o'rnatishni imkonsiz qilamiz.

Server platformalari CD / DVD disklari bilan ta'minlanmaganligi sababli, muammoni hal qilishning yagona echimi drayverlarni to'g'ridan-to'g'ri operatsion tizim tarqatilishiga qo'shish edi. Faqat USB 3.0 tekshiruvi drayverlarini birlashtirish va o'rnatish tasvirini tiklash orqali biz ushbu serverga Windows Server 2008 R2-ni o'rnatishga muvaffaq bo'ldik va bu holat bizning muhandislarimiz samarasiz urinishlarga vaqt sarflamasliklari uchun bizning ma'lumotlar bazamizga kiritilgan.

Hatto kulgili ham, mijozlar bizni jihozlash uchun jihozlarni olib kelishadi va kutilganidek ishlamaydi. Aynan shu narsa Dell PowerVault disk muhiti bilan sodir bo'ldi.

Qurilma - bu ikkita disk boshqaruvchisi va iSCSI protokoli orqali ishlash uchun tarmoq interfeyslari bo'lgan saqlash tizimi. Ushbu interfeyslarga qo'shimcha ravishda masofadan boshqarish uchun MGMT port mavjud.

Xostlangan uskunalar bo'yicha bizning xizmatlarimiz orasida faqat "10 Mbit / s qo'shimcha port" maxsus xizmati mavjud, agar serverni masofadan boshqarish vositalarini ulash zarur bo'lsa buyurtma qilinadi. Ushbu mablag'lar turli xil nomlarga ega:

  • Xewlett-Packarddan XMT;
  • Dell-dan IDrac;
  • Supermicro-dan IPMI.
Ularning funktsional imkoniyatlari taxminan bir xil - server holatini va masofaviy konsolga kirishni kuzatish. Shunga ko'ra, ularga yuqori kanal tezligi kerak emas - qulay ish uchun 10 Mbit / s etarli. Aynan ushbu xizmat mijoz tomonidan buyurtma qilingan. Biz mos mis o'zaro bog'lanishini o'rnatdik va tarmoq uskunamizning portini sozladik.

Tezlikni cheklash uchun port oddiygina 10BASE-T sifatida tuzilgan va maksimal 10 Mbit / s tezlikda xizmatga kiradi. Hamma narsa tayyor bo'lgandan so'ng, biz MGMT portini disk qutisini uladik, ammo mijoz deyarli darhol unga hech narsa ishlamayotganligini xabar qildi.

Kommutator portining holatini tekshirgandan so'ng, biz "Fizik havola ishlamayapti" degan noxush yozuvni topdik. Bunday yozuv kalit va unga ulangan mijoz uskunalari o'rtasida jismoniy aloqa bilan bog'liq muammolar mavjudligini ko'rsatadi.

Yomon siqilgan konnektor, singan konnektor, kabeldagi tomirlarning singanligi - bu havolaning yo'qligiga olib keladigan muammolarning kichik ro'yxati. Albatta, bizning muhandislarimiz zudlik bilan o'ralgan juftlik sinovini olib, ulanishni sinab ko'rishdi. Barcha tomirlar mukammal tarzda zil qilingan, kabelning ikkala uchi ham mukammal siqilgan. Bundan tashqari, ushbu kabelga sinov noutbukini ulab, biz kerak bo'lganda 10 Mbit / s ulanishga ega bo'ldik. Muammo mijozning apparat tomonida ekanligi aniq bo'ldi.

Muammolarni hal qilishda biz doimo mijozlarimizga yordam berishga harakat qilganimiz sababli, havola etishmasligining aniq sababini aniqlab olishga qaror qildik. MGMT port ulagichini sinchkovlik bilan ko'rib chiqdik - hammasi joyida.

Dasturiy ta'minot tomonidan ushbu portni "o'chirish" mumkinmi yoki yo'qligini aniqlashtirish uchun ishlab chiqaruvchining veb-saytidan asl foydalanish ko'rsatmalarini topdik. Biroq, bunday imkoniyat ko'zda tutilmagan - har holda, port avtomatik ravishda ko'tariladi. Bunday uskunalar har doim Auto-MDI (X) ni qo'llab-quvvatlashi kerakligiga qaramasdan - boshqacha qilib aytganda, qaysi simi ulanganligini aniqlash to'g'ri: normal yoki krossover, biz krossoverni eksperimental ravishda siqib, uni bir xil o'tish portiga uladik. Kommutator portidagi dupleks parametrni majburan ishlatishga harakat qildik. Effekt nolga teng edi - hech qanday aloqasi yo'q edi va g'oyalar allaqachon tugab qolgan edi.

Shu nuqtada muhandislardan biri bu uskunalar 10BASE-T ni qo'llab-quvvatlamaydi va faqat 100BASE-TX yoki hatto 1000BASE-X da ishlaydi degan aql-idrok taxminlariga mutlaqo zid bo'lgan. Odatda har qanday port, hatto eng arzon moslamada ham, 10BASE-T bilan mos keladi va dastlab muhandisning taxminlari "xayol" deb rad etildi, ammo umidsizliklar tufayli ular portni 100BASE-TX ga almashtirishga qaror qildilar.

Bizning ajablanishimiz chegara bilmas edi, havola darhol ko'tarildi. MGMT portida 10BASE-T qo'llab-quvvatlashining etishmasligiga aynan nima sabab bo'lganligi sir bo'lib qolmoqda. Bunday hodisa juda kam uchraydi, lekin uning bor joyi bor.

Mijoz biznikidan kam ajablanmadi va muammoni hal qilgani uchun unga katta minnatdorchilik bildirdi. Shunga ko'ra, ular portni 100BASE-TX-da tark etib, portdagi tezlikni to'g'ridan-to'g'ri o'rnatilgan stavka cheklash mexanizmi yordamida cheklashdi.

Sovutish turbinasining ishdan chiqishi

Bir marta bizga mijoz kelib, serverni olib tashlashni va xizmat ko'rsatish zonasiga olib borishni so'radi. Muhandislar hamma narsani qildilar va uni uskunalar bilan yolg'iz qoldirdilar. Bir soat o'tdi, ikkinchisi, uchinchisi - mijoz serverni ishga tushirishni to'xtatdi va biz muammo nima ekanligini so'radik.

Ma'lum bo'lishicha, Hewlett-Packard tomonidan ishlab chiqarilgan server oltita sovutish turbinasidan ikkitasida ishlamay qolgan. Shu bilan birga, server yoqiladi, sovutishda xatolik yuz beradi va darhol o'chadi. Shu bilan birga, server juda muhim xizmatlarga ega bo'lgan hipervizorni joylashtiradi. Xizmatlarning normal ishlashini tiklash uchun virtual mashinalarning boshqa jismoniy tugunga shoshilinch ko'chishini amalga oshirish kerak edi.

Biz mijozga quyidagi tarzda yordam berishga qaror qildik. Odatda server inqiloblar sonini o'qish orqali sovutish foniy bilan hammasi yaxshi ekanligini tushunadi. Shu bilan birga, albatta, Hewlett-Packard muhandislari asl pervanenin analog bilan almashtirilishiga yo'l qo'ymaslik uchun hamma narsani qildilar - nostandart ulagich, nostandart pinout.

Bunday qismning asl nusxasi taxminan 100 dollar turadi va siz shunchaki borib sotib olmaysiz - uni chet eldan buyurtma qilishingiz kerak. Yaxshiyamki, Internetda ular asl pog'onali sxemani topdilar va pinlardan biri shunchaki soniyada dvigatel aylanishining sonini o'qish uchun javobgar ekanligini aniqladilar.

Qolganlari texnologiya bilan bog'liq edi - ular prototipni yaratish uchun bir nechta simlarni olishdi (tasodifan ular qo'lida edi - bizning ba'zi muhandislarimiz Arduinoni yaxshi ko'rishadi) va shunchaki qo'shni ishchi turbinalardan pimlarni ishlamay qolgan ulagichlar bilan bog'lashdi. Server ishga tushdi va mijoz nihoyat virtual mashinalarni ko'chirishga va xizmatlarni ishga tushirishga muvaffaq bo'ldi.

Albatta, bularning barchasi faqat mijozning javobgarligi ostida amalga oshirildi, ammo oxir-oqibat, bunday nostandart harakat to'xtab qolish vaqtini minimal darajaga kamaytirishga imkon berdi.

Disklar qayerda?

Ba'zi hollarda, muammoning sababi ba'zan shunchalik ahamiyatsizki, uni topish juda uzoq vaqt talab etadi. Shunday qilib, bizning mijozlarimizdan biri tasodifiy disklar va serverning muzlashi haqida shikoyat qilganida shunday bo'ldi. Uskuna platformasi - Supermicro 847 kassada (4U form faktor) 36 ta drayverni ulash uchun katakchalari bilan. Serverda uchta bir xil Adaptec RAID tekshiruvi mavjud edi, ularning har biri 12 ta disk biriktirilgan. Muammo yuz berganda, server tasodifiy sonli disklarni ko'rishni to'xtatdi va osib qo'ydi. Server ishlab chiqarishdan chiqarildi va diagnostika ishlarini boshladi.

Biz bilib olgan birinchi narsa - disklar faqat bitta tekshirgichga tushib qoldi. Shu bilan birga, "tushirilgan disklar" mahalliy Adaptec boshqaruv dasturidagi ro'yxatdan g'oyib bo'ldi va faqat server to'liq o'chirilgandan so'ng qayta ulangandan keyin paydo bo'ldi. Aqlga kelgan birinchi narsa kontroller dasturi edi. Uchala tekshirgichda ham bir oz farqli proshivka bor edi, shuning uchun barcha kontrollerlarga bir xil proshivka versiyasini o'rnatishga qaror qilindi. Bajarildi, biz serverni maksimal yuklash rejimlarida boshqardik - barchasi kutilganidek ishlaydi. Muammoni echilgan deb belgilab bo'lgach, server mijozga ishlab chiqarishga qaytarib yuborildi.

Ikki hafta o'tgach, yana o'sha muammo bilan davolanish. Tekshirgichni shunga o'xshash bilan almashtirishga qaror qilindi. Bajarildi, chaqnadi, ulandi, sinovlarga qo'yildi. Muammo saqlanib qoldi - bir necha kundan keyin yangi tekshirgichdagi barcha disklar tushib ketdi va server xavfsiz tarzda o'chib qoldi.

Tekshirgichni boshqa uyaga qayta o'rnatdik, orqa panel va SATA kabellarini tekshirgichdan orqa panelga almashtirdik. Bir haftalik sinovlar va yana disklar tushib ketdi - server yana muzlab qoldi. Adaptec-ni qo'llab-quvvatlash bilan bog'lanish muvaffaqiyatsiz tugadi - ular uchta tekshirgichni tekshirdilar va hech qanday muammo topmadilar. Biz anakartni almashtirdik, platformani deyarli noldan tikladik. Eng kichik shubha tug'dirgan hamma narsa yangisiga almashtirildi. Va muammo yana paydo bo'ldi. Tasavvuf va boshqa hech narsa yo'q.

Har bir diskni alohida tekshirishni boshlaganlarida muammo tasodifan hal qilindi. Muayyan yuk paytida disklardan biri boshlarini urishni boshladi va signal signalizatsiyasi bo'lmaganida SATA portiga qisqa tutashuvni berdi. Shu bilan birga, kontroller ba'zi disklarni ko'rishni to'xtatdi va ularni qayta elektr ta'minoti bilan qayta ulangandan so'nggina taniy boshladi. Bitta yomon disk butun server platformasini chiqarib tashladi.

Xulosa

Albatta, bu bizning muhandislarimiz tomonidan hal qilingan qiziqarli vaziyatlarning kichik bir qismi. Ba'zi muammolarni "ushlash" qiyin, ayniqsa, muvaffaqiyatsizliklar jurnallarida hech qanday ishora yo'q. Ammo har qanday bunday holat muhandislarni server uskunalari dizaynini batafsil tushunishga va muammolarga turli xil echimlarni topishga undaydi.

Mana bizning amaliyotimizdagi ba'zi kulgili holatlar.
Siz nimaga duch keldingiz? Izohlarga xush kelibsiz.

Oddiy foydalanuvchi, qoida tariqasida, "veb-server" yoki "xosting" kabi tushunchalarni umuman tushunarsiz narsa bilan bog'laydi. Ayni paytda, bu masalada murakkab narsa yo'q. Keling, veb-server nima ekanligini, nima uchun kerakligini va qanday ishlashini texnik tafsilotlarga berilmasdan, ammo, shunday qilib aytganda, barmoqlar bilan tushuntirishga harakat qilaylik. Uydagi kompyuter terminalida yoki noutbukda bunday serverni qanday yaratish va sozlash haqida alohida to'xtalamiz.

Veb-server nima?

Bu masala bo'yicha eng muhimi, ushbu turdagi server Internetda mos keladigan dastur o'rnatilgan kompyuterdan boshqa narsa emasligini tushunishdir.

Ammo bu mutlaqo siz o'zingizning konfiguratsiyangizni uyda yaratolmaysiz degani emas. Bizda Windows operatsion tizimlari keng tarqalganligi sababli Ubuntu (Linux) da veb-serverni qanday yaratish haqida savollar ko'rib chiqilmaydi.

Veb-serverlar nima uchun kerak?

Ushbu turdagi serverlarda Internetda ko'plab ma'lumotlar saqlanadi. Shu bilan birga, xuddi shu antiviruslar o'zlarining ma'lumotlar bazalarini yangilash uchun ularga murojaat qilishadi. Shuningdek, foydalanuvchi brauzerda so'rovlarni to'ldirib, bunday serverlar bilan bevosita bog'liqdir (ma'lumot qidirish, sahifaga murojaat qilish va hk).

Shunday qilib, Internetdagi barcha sahifalar veb-serverlarda aniq saqlanadigan bo'lib, unga bir tomondan foydalanuvchi so'rovi yoki o'rnatilgan dastur murojaat qilingan, ikkinchidan, natijani kirish uchun harakat qilingan o'sha server qaytaradi.

Hammasi qanday ishlaydi?

Barcha foydalanuvchilar ma'lum bir turdagi ma'lumotlarni o'z ichiga olgan Internetdagi (veb-sahifadagi) ba'zi manbalarni kiritish uchun www (yoki http) prefiksi va undan keyingi ism manzil satriga oddiygina kiritilishiga odatlangan. Ammo veb-server so'rovni qanday tushunishi va natijani berishi haqida hech kim o'ylamaydi.

Aslida, bu erda siz server va mijoz tushunchalarini farqlashingiz kerak. Bizning holatda, Internetdagi sahifa uzoq serverda saqlanadi. Foydalanuvchi kompyuter so'rov qilingan mijoz sifatida ishlaydi.

Internetga kirish uchun veb-brauzerlar deb nomlangan dasturlardan foydalaniladi. Ular foydalanuvchining so'rovini veb-server tanigan raqamli kodga aylantiradi. Server uni qayta ishlaydi va tegishli kodda javob beradi va brauzer allaqachon millionlab nol va bittasini sahifaga joylashtirilgan matn, grafik, tovush yoki video ma'lumotlari bilan oddiy shaklga o'zgartiradi.

Eng mashhur veb-serverlar

Barcha server dasturlaridan Apache va Microsoft IIS eng keng tarqalgan deb hisoblanadi. Birinchisi yanada ommabop bo'lib, asosan Windows muhitida o'rnatilishi mumkin bo'lsa-da, asosan UNIXga o'xshash tizimlarda qo'llaniladi. Bundan tashqari, Apache butunlay bepul dasturiy ta'minot va deyarli barcha ma'lum operatsion tizimlarga mos keladi. Biroq, ta'kidlanganidek, ushbu dastur asosan professional dasturchilar va ishlab chiquvchilar uchun mo'ljallangan.

Microsoft tomonidan ishlab chiqarilgan dasturiy ta'minot malakali mutaxassisning qo'shimcha yordamisiz Windows uchun bunday veb-serverni o'rnatishi va sozlashi mumkin bo'lgan o'rtacha foydalanuvchi uchun mo'ljallangan.

Shunga qaramay, rasmiy statistik ma'lumotlarga asoslanib, Apache dasturiy ta'minoti barcha mavjud serverlarning taxminan 60 foizidan foydalanadi, shuning uchun biz uning namunasi yordamida dastlabki konfiguratsiyani o'rnatish va sozlash masalasini ko'rib chiqamiz.

Uydagi veb-server: o'rnatish

O'rnatish uchun sizga uchta asosiy komponentni o'z ichiga olgan WAMP sifatida qisqartirilgan maxsus server paketini yuklab olishingiz kerak bo'ladi:

  • Apache - bu o'z-o'zidan ishlashi mumkin bo'lgan, ammo joylashtirilgan sahifalarda dinamik tarkib bo'lmasa, server dasturiy ta'minotining qobig'i.
  • PHP - bu WordPress, Joomla, Drupal kabi dinamik tarkibga ega serverlarni boshqarish uchun qo'shimchalar tomonidan ishlatiladigan dasturlash tili.
  • MySQL - bu dinamik tarkibga ega saytlarni yaratishda ishlatiladigan yana bir marotaba ma'lumotlar bazasini boshqarish tizimi.

O'rnatish WampServer paketidan amalga oshirilishi mumkin. Buning uchun bosqichlardan birida sukut bo'yicha ishlatiladigan Internet-brauzerni tanlashni taklif qiladigan "Sehrgar" ko'rsatmalariga amal qilish kifoya.

Buning uchun brauzerning bajariladigan fayli joylashgan papkaga o'tishingiz kerak bo'ladi (agar u Internet Explorer bo'lmasa, u odatda Program Files katalogida joylashgan). Yo'l davomida brauzerning o'zi Windows xavfsizlik devori istisnolari ro'yxatiga qo'shilishi kerak. Oxirgi bosqichda darhol ishga tushirish elementining oldiga tasdiq belgisi qo'yiladi, shundan so'ng tizim tepsisida tegishli belgi paydo bo'ladi, uni bosishingiz va o'zgartirishingiz kerak mahalliy xost (localhost) ishga tushirilishini tanlang.

Agar hamma narsa to'g'ri bajarilgan bo'lsa, serverning asosiy sahifasi paydo bo'ladi. Keyinchalik, sizga qo'shimcha komponentlarni o'rnatish taklif qilinadi (agar bu bajarilmasa, tizim xatoga yo'l qo'yadi). Asosan, o'rnatish kelajakda server tomonidan ishlatiladigan qo'shimcha qo'shimchalar, elementlar va tarkibiy qismlarga tegishli.

Serverni sozlash va sinovdan o'tkazish uchun namuna

Veb-serverni sozlash biroz murakkabroq. Birinchidan, tizim laganda menyusida siz WWW jildiga o'tishni tanlaysiz (bu erda qo'shimchalar yoki HTML fayllar saqlanadi). Shundan so'ng, quyidagi matnni bloknotga yozing:

WAMP testi!

Salom!

"; ?>

Siz faqat matnni bloknotga nusxalashingiz va faylni index.php nomi ostida xuddi shu WWW papkasida saqlashingiz mumkin (garchi siz buni amalga oshirsangiz ham bo'ladi, chunki bu qadam faqat mahalliy xostni tekshirish uchun ishlatiladi). Salomlashish o'rniga har qanday boshqa matn yoki iborani kiritishingiz mumkin.

Keyin brauzerda sahifani yangilashingiz kerak (F5), undan so'ng tarkib ekranda ko'rsatiladi. Ammo sahifa boshqa kompyuterlar uchun mavjud bo'lmaydi.

Kirishni ochish uchun httpd.conf faylini boshlangan qismga yozish orqali o'zgartirishingiz kerak quyidagi satrlar:

Buyurtma berish, rad etish

Keyingi so'z o'rniga

Albatta, uy veb-serverining ishlashi yoki sozlamalarining mohiyatini tushunishga kelsak, bu erda umumiy tushuncha uchun faqat eng oddiy va qisqacha ma'lumotlar berilgan. Darhaqiqat, barcha jarayonlar ancha murakkab, ayniqsa, so'rovlarni konvertatsiya qilish va javoblarni berish nuqtai nazaridan, uyda serverni o'rnatish haqida gapirmaslik kerak. Agar foydalanuvchi ushbu masalalarni tushunishni xohlasa, unda hech bo'lmaganda bir xil WordPress qo'shimchasi va PHP tilini bilmasdan qila olmaydi. Boshqa tomondan, siz ushbu dastlabki ma'lumotlardan asosan faqat matnli ma'lumotlarni o'z ichiga olgan ibtidoiy sahifalarni nashr etish uchun foydalanishingiz mumkin.

Veb-server nima? Oddiy odam nuqtai nazaridan, bu brauzer so'rovlarini qayta ishlaydigan va javoban veb-sahifalarni chiqaradigan bir xil qora quti. Texnik sizni bir tonna tushunarsiz atamalar bilan bombardimon qiladi. Natijada, yangi boshlagan veb-server ma'murlari uchun turli xil atamalar va texnologiyalarni tushunish qiyin bo'lishi mumkin. Darhaqiqat, veb-ishlab chiqarish sohasi jadal rivojlanmoqda, ammo ko'plab zamonaviy echimlar asosiy texnologiyalar va tamoyillarga asoslangan bo'lib, ular haqida bugun gaplashamiz.

Agar siz qayerdan boshlashni bilmasangiz, demak, boshidan boshlashingiz kerak. Zamonaviy veb-texnologiyalarning xilma-xilligi bilan aralashmaslik uchun siz zamonaviy Internet qaerdan boshlanganini va texnologiyalar qanday rivojlangan va takomillashganligini bilish uchun tarixga murojaat qilishingiz kerak.

HTTP-server

Internet taraqqiyotining boshida saytlar maxsus belgilangan hujjatlar va ularga tegishli ba'zi ma'lumotlar: fayllar, rasmlar va boshqalarni oddiy ombori edi. Hujjatlar bir-biriga va tegishli ma'lumotlarga murojaat qilishlari uchun HTML-ning maxsus gipermatnli belgilash tili taklif qilingan va Internetga HTTP protokoli orqali bunday hujjatlar kirishi mumkin. Rivojlanayotgan va takomillashgan til ham, protokol ham bugungi kungacha sezilarli o'zgarishsiz saqlanib qoldi. 1999 yilda qabul qilingan HTTP / 1.1 protokolini almashtirishni boshlagan HTTP / 2 protokoli zamonaviy tarmoq talablarini inobatga olgan holda tub o'zgarishlarni amalga oshirmoqda.

HTTP protokoli mijoz-server texnologiyasi yordamida amalga oshiriladi va fuqaroligi bo'lmagan so'rovga javob berish printsipi asosida ishlaydi. So'rovning maqsadi aniqlangan resursdir bitta resurs identifikatori - URI (Resursning yagona identifikatori), HTTP URI lazzatlaridan birini ishlatadi - Url (Resurslarni bir xil aniqlovchi) - universal resurs qidiruvchisi, bu resurs haqida ma'lumotdan tashqari, uning jismoniy joylashishini ham belgilaydi.

HTTP serverining vazifasi mijozning so'rovini qayta ishlash va unga so'ralgan manbani berish yoki buning iloji yo'qligi to'g'risida xabar berishdir. Quyidagi diagrammani ko'rib chiqing:


HTTP mijozi, ko'pincha brauzer orqali foydalanuvchi HTTP serveridan URL manzilini so'raydi, server tegishli URL faylini, odatda HTML sahifasini tekshiradi va yuboradi. Olingan hujjat rasmlar kabi tegishli manbalarga havolalarni o'z ichiga olishi mumkin. Agar ular sahifada ko'rsatilishi kerak bo'lsa, mijoz ularni serverdan ketma-ket so'raydi, qo'shimcha ravishda rasmlar, uslublar jadvallari, mijoz tomonida bajarilgan skriptlar va hk. Barcha kerakli manbalarni olgan brauzer ularni HTML hujjat kodiga muvofiq qayta ishlaydi va foydalanuvchiga tugallangan sahifani beradi.

Ko'pchilik allaqachon taxmin qilganidek, HTTP-server nomi ostida ushbu sxema bugungi kunda veb-server sifatida yaxshi tanilgan shaxsni o'z ichiga oladi. Veb-serverning asosiy maqsadi va vazifasi HTTP so'rovlarini qayta ishlash va natijalarini foydalanuvchiga qaytarishdir. Veb-server o'z-o'zidan tarkibni qanday yaratishni bilmaydi va faqat statik tarkib bilan ishlaydi. Bu ularning imkoniyatlarining barcha boyligiga qaramay, zamonaviy veb-serverlar uchun ham amal qiladi.

Uzoq vaqt davomida to'liq veb-saytni amalga oshirish uchun bitta veb-server etarli edi. Ammo Internet o'sib borishi bilan statik HTMLning imkoniyatlari juda kamlashdi. Oddiy misol: har bir statik sahifa o'zini o'zi ta'minlashi va barcha tegishli manbalarga havolalarni o'z ichiga olishi kerak; yangi sahifalarni qo'shishda ularga havolalarni mavjud sahifalarga qo'shish kerak bo'ladi, aks holda foydalanuvchi hech qachon ularga kira olmaydi.

O'sha paytdagi saytlar umuman zamonaviylarga o'xshamagan, masalan, Rambler kompaniyasining sayti rus tilidagi Internet kashshoflaridan biri:

Umuman olganda, biron bir havolaga o'tish zamonaviy foydalanuvchini sarosimaga solishi mumkin, brauzerda xuddi shu nomdagi tugmani bosishdan tashqari, bunday sahifadan orqaga qaytish mumkin emas.

Zamonaviy saytga o'xshash yoki ozroq o'xshash narsalarni yaratishga urinish, tez orada mavjud sahifalarga o'zgartirishlar kiritish bo'yicha ishlarning ko'payishiga aylandi. Axir, agar biz saytning umumiy qismida biror narsani o'zgartirgan bo'lsak, masalan, sarlavhadagi logotipni o'zgartirgan bo'lsak, unda biz ushbu o'zgarishni barcha mavjud sahifalarga kiritishimiz kerak. Agar biz sahifalardan biriga yo'lni o'zgartirgan bo'lsak yoki uni o'chirib tashlagan bo'lsak, unda biz unga barcha havolalarni topib, ularni o'zgartirishimiz yoki o'chirishimiz kerak bo'ladi.

Shuning uchun veb-serverlarni rivojlantirishning navbatdagi bosqichi texnologiyani qo'llab-quvvatlash edi server tomoni o'z ichiga oladi - SSI (Server tomoni o'z ichiga oladi). Sahifa kodiga boshqa fayllarning tarkibini kiritishga imkon berdi, bu esa takroriy elementlarni, masalan, sarlavha, altbilgi, menyu va boshqalarni ko'rsatishga imkon berdi. alohida fayllarga joylashtiring va uni sahifani yakuniy yig'ish paytida qo'shib qo'ying.

Endi logotipni yoki menyu bandini o'zgartirish uchun barcha mavjud sahifalarni tahrirlash o'rniga faqat bitta faylda o'zgartirishlar kiritish kerak bo'ladi. Bundan tashqari, SSI ba'zi dinamik tarkibni sahifalarda ko'rsatishga imkon berdi, masalan, haqiqiy sana va oddiy shartlarni bajarish va o'zgaruvchilar bilan ishlash. Bu veb-ustalarni osonlashtiradigan va foydalanuvchi tajribasini yaxshilaydigan oldinga siljish edi. Biroq, ushbu texnologiyalar hali ham haqiqiy veb-saytni amalga oshirishga imkon bermadi.

Shuni ta'kidlash kerakki, SSI bugungi kunda faol foydalanilmoqda, bu erda sahifaning kodiga ba'zi statik tarkibni kiritish kerak, bu avvalo uning soddaligi va oddiy manbalari bilan bog'liq.

CGI

Veb-texnologiyalarni rivojlantirishning navbatdagi bosqichi server tomonida foydalanuvchi so'rovlarini qayta ishlaydigan maxsus dasturlar (skriptlar) paydo bo'lishi bo'ldi. Ko'pincha ular skript tillarida yoziladi, dastlab Perl edi, bugungi kunda PHP kaftini ushlab turibdi. Asta-sekin, dasturlarning butun sinfi paydo bo'ldi - tarkibni boshqarish tizimlari - CMS (Tarkibni boshqarish tizimi), bu foydalanuvchi so'rovlarini dinamik qayta ishlashni ta'minlashga qodir bo'lgan to'liq veb-dasturlarni namoyish etadi.

Endi muhim bir nuqta: veb-serverlar skriptlarni bajarmagan va bajarolmaydilar, ularning vazifasi statik tarkibga xizmat qilishdir. Bu erda sahnaga yangi sub'ekt - skript tillarining tarjimoni bo'lgan va ularda yozilgan veb-ilovalar ishlaydigan dastur serveri kiradi. Ma'lumotlarni saqlash uchun odatda DBMS ishlatiladi, bu katta hajmdagi o'zaro bog'liq ma'lumotlarga kirish zarurati bilan bog'liq.

Biroq, dastur serveri HTTP protokoli bilan ishlashni va foydalanuvchi so'rovlarini qayta ishlashni bilmaydi, chunki bu veb-serverning vazifasi. Ularning o'zaro ta'sirini ta'minlash uchun ishlab chiqilgan umumiy shlyuz interfeysi - CGI (Umumiy shlyuz interfeysi).

Shuni aniq tushunish kerakki, CGI dastur yoki protokol emas, bu shunchaki interfeys, ya'ni. ilovalar orasidagi o'zaro ta'sir usullarining to'plami. Shuningdek, CGI atamasini CGI interfeysi orqali ishlashni qo'llab-quvvatlaydigan dastur (skript) ni anglatuvchi CGI dasturi yoki CGI skripti tushunchasi bilan adashtirmang.

Ma'lumotlarni uzatish uchun veb-serverdan CGI dasturiga standart kirish-chiqish oqimlari ishlatiladi, ma'lumotlar uzatiladi stdinorqali qaytarib olinadi stdout, xato xabarlarini yuborish uchun foydalaning stderr.

Keling, bunday tizimning jarayonini batafsil ko'rib chiqaylik. Foydalanuvchi brauzeridan so'rov olgandan so'ng, veb-server dinamik tarkib talab qilinishini aniqlaydi va maxsus so'rov yaratadi, uni CGI interfeysi orqali veb-dasturga yuboradi. Qabul qilingandan so'ng, dastur so'rovni boshlaydi va bajaradi, natijada dinamik ravishda yaratilgan sahifaning HTML kodi paydo bo'ladi, u veb-serverga qayta yuboriladi, undan so'ng dastur chiqadi.

Dinamik saytning yana bir muhim farqi shundaki, uning sahifalari foydalanuvchiga taqdim etilgan shaklda jismonan mavjud emas. Aslida, veb-dastur mavjud, ya'ni. skriptlar va shablonlar to'plami va sayt materiallari va xizmat ma'lumotlarini saqlaydigan ma'lumotlar bazasi, statik tarkib alohida joylashtirilgan: rasmlar, java skriptlari, fayllar.

So'rovni olgandan so'ng, veb-dastur ma'lumotlar bazasidan ma'lumotlarni chiqaradi va so'rovda ko'rsatilgan shablonni to'ldiradi. Natijada veb-serverga yuboriladi, u shu bilan shakllangan sahifani statik tarkib (rasmlar, skriptlar, uslublar) bilan to'ldiradi va foydalanuvchi brauzeriga beradi. Sahifaning o'zi hech qanday joyda saqlanmaydi, faqat keshdan tashqari va yangi so'rov qabul qilinganda sahifa qayta yaratiladi.

CGI afzalliklari qatoriga til va arxitektura mustaqilligi kiradi: CGI dasturi istalgan tilda yozilishi va har qanday veb-server bilan teng darajada ishlashi mumkin. Standartning soddaligi va ochiqligini hisobga olib, bu veb-dasturlarning tezkor rivojlanishiga olib keldi.

Biroq, afzalliklardan tashqari, CGI ham muhim kamchiliklarga ega. Asosiysi - bu jarayonni boshlash va to'xtatish uchun yuqori qo'shimcha xarajatlar, bu apparat resurslariga talablarning oshishiga va past ishlashga olib keladi. Va standart I / O oqimlaridan foydalanish miqyosi va yuqori mavjudlikni cheklaydi, chunki bu veb-server va dastur serverlari bir tizimda bo'lishini talab qiladi.

Hozirgi vaqtda CGI amalda qo'llanilmaydi, chunki uning o'rnini yanada ilg'or texnologiyalar egalladi.

FastCGI

Nomidan ko'rinib turibdiki, ushbu texnologiyani ishlab chiqishning asosiy maqsadi CGI ko'rsatkichlarini yaxshilash edi. Keyingi rivojlanishi sifatida FastCGI - bu yuqori darajadagi ishlash va xavfsizlikni ta'minlaydigan veb-server va dastur serverlari o'rtasidagi o'zaro aloqalar uchun mijoz-server protokoli.

FastCGI CGI-ning asosiy muammosini yo'q qiladi - har bir so'rov uchun veb-dastur jarayonini qayta boshlash, FastCGI jarayonlari doimiy ravishda ishlaydi, bu vaqt va resurslarni sezilarli darajada tejashga imkon beradi. Standart oqimlar o'rniga ma'lumotlarni uzatish uchun foydalaniladi UNIX soketlari yoki TCP / IP, bu sizga veb-server va dastur serverlarini turli xil xostlarda joylashtirishga imkon beradi va shu bilan tizimning miqyosi va / yoki yuqori mavjudligini ta'minlaydi.

Biz bir nechta FastCGI jarayonlarini bitta kompyuterda bajarishimiz mumkin, ular so'rovlarni parallel ravishda ishlashi yoki skript tilining turli xil sozlamalari yoki versiyalariga ega bo'lishi mumkin. Masalan, siz bir vaqtning o'zida turli xil saytlar uchun bir nechta PHP versiyalariga ega bo'lishingiz mumkin, ularning so'rovlarini turli FastCGI jarayonlariga yuborishingiz mumkin.

Jarayon menejerlari FastCGI jarayonlarini boshqarish va yuklarni muvozanatlash uchun ishlatiladi; ular veb-serverning bir qismi yoki alohida dasturlar bo'lishi mumkin. Ommabop Apache va Lighttpd veb-serverlarida o'rnatilgan FastCGI jarayon menejerlari mavjud, Nginx esa FastCGI bilan ishlash uchun tashqi menejerni talab qiladi.

PHP-FPM va spawn-fcgi

PHP-FPM va spawn-fcgi tashqi menejerlaridan FastCGI jarayonlari uchun foydalaniladi. PHP-FPM dastlab Andrey Nigmatulindan tuzilgan PHP patchlar to'plami bo'lib, u FastCGI jarayonini boshqarishning bir qator masalalarini hal qildi, 5.3 versiyadan boshlab, bu loyihaning bir qismi va PHP tarqatilishiga kiritilgan. PHP-FPM PHP jarayonlarining sonini yukiga qarab dinamik ravishda boshqarishi, so'rovlarni yo'qotmasdan hovuzlarni qayta yuklashi, muvaffaqiyatsiz bo'lgan jarayonlarni favqulodda qayta boshlashi va ancha rivojlangan menejer.

Spawn-fcgi Lighttpd loyihasining bir qismidir, lekin shu nomdagi veb-serverga kiritilmagan; sukut bo'yicha Lighttpd o'zining oddiy, sodda, protsesse menejeridan foydalanadi. Ishlab chiquvchilar uni boshqa xostda joylashgan FastCGI jarayonlarini boshqarish kerak bo'lgan yoki rivojlangan xavfsizlik sozlamalari kerak bo'lgan hollarda foydalanishni tavsiya etadilar.

Tashqi menejerlar har bir FastCGI jarayonini ajratib turishga imkon beradi (dasturning ildiz katalogini undan tashqariga kirish imkoniyatisiz o'zgartirish), boshqa jarayonlarning xrootidan ham, veb-serverning xronidan ham farq qiladi. Yuqorida aytib o'tganimizdek, ular TCP / IP orqali boshqa serverlarda joylashgan FastCGI dasturlari bilan ishlashga imkon beradi, agar mahalliy kirish bo'lsa, siz tez ulanish turi sifatida UNIX soket orqali kirishni tanlashingiz kerak.

Agar sxemaga yana bir bor nazar tashlasak, bizda yangi element - veb-server va dastur serverlari o'rtasida vositachi bo'lgan jarayon menejeri borligini ko'ramiz. Bu sxemani biroz murakkablashtiradi, chunki ko'p sonli xizmatlarni sozlash va saqlash kerak, ammo shu bilan birga u sizning vazifalaringiz uchun serverning har bir elementini aniq sozlashingiz mumkin bo'lgan keng imkoniyatlarni ochib beradi.

Amalda, o'rnatilgan menejer va tashqi menejer o'rtasida tanlov qilishda vaziyatni yaxshilab baholang va aynan sizning ehtiyojlaringizga mos vositani tanlang. Masalan, standart dvigatellarda bir nechta saytlar uchun oddiy server yaratish, tashqi menejerdan foydalanish aniq ortiqcha bo'ladi. Garchi hech kim o'z nuqtai nazarini sizga yuklamasa ham. Linux yaxshi, chunki har kim, konstruktor kabi, aynan kerakli narsani yig'ishi mumkin.

SCGI, PCGI, PSGI, WSGI va boshqalar

Veb-ishlab chiqish mavzusiga sho'ng'ib, siz shubhasiz CGI texnologiyalari haqida so'z yuritasiz, ularning ichida eng mashhurlari biz sarlavhada keltirilgan. Siz bunday xilma-xillikdan chalkashib ketishingiz mumkin, ammo agar siz maqolamizning boshini diqqat bilan o'qib chiqsangiz, CGI va FastCGI qanday ishlashini bilasiz va shuning uchun ushbu texnologiyalardan biri bilan ishlash siz uchun qiyin bo'lmaydi.

Muayyan echimni amalga oshirishdagi farqlarga qaramay, asosiy tamoyillar umumiy bo'lib qolmoqda. Ushbu texnologiyalarning barchasi shlyuz interfeysini ta'minlaydi ( Gateway interfeysi) veb-server va dastur serverlari o'rtasida aloqa o'rnatish. Gateways veb-server va veb-dastur muhitini ajratib olishga imkon beradi, bu esa har qanday kombinatsiyani mumkin bo'lgan nomuvofiqlikni hisobga olmagan holda ishlatishga imkon beradi. Oddiy qilib aytganda, kerakli turdagi shlyuz bilan ishlashga qodir bo'lgan veb-serveringiz ma'lum bir texnologiyani yoki skript tilini qo'llab-quvvatlashi muhim emas.

Va sarlavhada qisqartirilganlarning bir guruhini sanab o'tganimiz sababli, biz ularni batafsilroq ko'rib chiqamiz.

SCGI (Oddiy umumiy shlyuz interfeysi) - oddiy umumiy shlyuz interfeysi - CGI-ga alternativ sifatida ishlab chiqilgan va ko'p jihatdan FastCGI-ga o'xshash, ammo amalga oshirish osonroq. Biz FastGCI bilan bog'liq bo'lgan barcha narsalar SCGI uchun ham to'g'ri keladi.

PCGI (Perl umumiy shlyuz interfeysi) - bu CGI interfeysi bilan ishlash uchun Perl kutubxonasi, uzoq vaqt davomida bu Perl dasturlari bilan CGI orqali ishlashning asosiy varianti bo'lib, u kam ishlash talablariga ega va ortiqcha yuklardan yaxshi himoyalangan (CGIga taalluqli) yaxshi ishlashga ega.

PSJI (Perl veb-serverining shlyuz interfeysi) - bu veb-server va Perl uchun dastur serveri o'rtasidagi o'zaro ta'sir o'tkazish texnologiyasi. Agar PCGI klassik CGI interfeysi bilan ishlash vositasi bo'lsa, unda PSGI ko'proq FastCGI ga o'xshaydi. PSGI Server doimiy ravishda xizmat sifatida ishlaydigan va veb-server bilan TCP / IP yoki UNIX soketlari orqali aloqa o'rnatadigan Perl dasturlarini bajarish uchun asos yaratadi va Perl dasturlariga FastCGI bilan bir xil imtiyozlarni taqdim etadi.

WSGI (Veb-server shlyuz interfeysi) - bu Phyton-da yozilgan dasturlar uchun veb-serverning dastur serveri bilan o'zaro aloqasi uchun mo'ljallangan yana bir o'ziga xos shlyuz interfeysi.

Biz sanab o'tgan barcha texnologiyalar, u yoki bu darajada, CGI / FastCGI analoglari ekanligini ko'rish oson, ammo ma'lum dastur sohalari uchun. Biz bergan ma'lumotlar ularning ishlash tamoyillari va mexanizmlarini umumiy tushunish uchun etarli bo'ladi va ularni chuqurroq o'rganish faqat ko'rsatilgan texnologiyalar va tillar bilan jiddiy ish olib borilganda mantiqiy bo'ladi.

Apache moduli sifatida dastur serveri

Agar ilgari biz qandaydir mavhum veb-server haqida gapirgan bo'lsak, endi ma'lum bir echim haqida gaplashamiz va bu erda gap bizning afzalliklarimizda emas. Veb-serverlar orasida Apache alohida o'rin tutadi, aksariyat hollarda ular Linux platformasidagi veb-server haqida va umuman veb-server haqida gaplashganda, Apache nazarda tutiladi.

Aytish mumkinki, bu bir xil "standart" veb-server. Har qanday ommaviy xostingdan foydalaning - Apache u erda bo'ladi, har qanday veb-ilovani oling - standart sozlamalar Apache uchun qilingan.

Ha, texnologik nuqtai nazardan Apache texnologiyalarning toji emas, balki aynan u oltin o'rtacha, sodda, aniq, moslashuvchan, universaldir. Agar siz saytni qurishda birinchi qadamlaringizni qo'yayotgan bo'lsangiz, unda Apache sizning tanlovingizdir.

Bu erda biz Apache uzoq vaqtdan beri eskirgan, barcha "haqiqiy yigitlar" allaqachon Nginx-ni o'rnatgan va h.k. va hokazo, shuning uchun ushbu daqiqani batafsilroq tushuntirib beramiz. Qutidagi barcha mashhur CMS-lar Apache bilan birgalikda ishlatilishi uchun tuzilgan, bu sizga barcha e'tiborni veb-dastur bilan ishlashga yo'naltirishga imkon beradi.

Yangi boshlanuvchilar orasida ommabop bo'lgan barcha forumlar, shuningdek, veb-server sifatida Apache-ni anglatadi va ko'pgina maslahatlar va tavsiyalar unga tegishli bo'ladi. Shu bilan birga, muqobil veb-serverlar odatda veb-server tomonidan ham, veb-dastur tomonidan ham nozik va puxta konfiguratsiyani talab qiladi. Shu bilan birga, ushbu mahsulotlarning foydalanuvchilari odatda ancha tajribali va yangi kelganlarning atrof-muhitdagi odatdagi muammolari muhokama qilinmaydi. Natijada, hech narsa ishlamay qolganda va hech kim so'ramaydigan vaziyat yuzaga kelishi mumkin. Apache bilan bunday bo'lmasligi kafolatlanadi.

Aslida, Apache ishlab chiquvchilari o'zlarining aql-idroklariga alohida o'rin olishiga imkon beradigan nima qildilar? Javob etarlicha sodda: ular o'z yo'llari bilan ketishdi. CGI universal shlyuzga e'tibor qaratib, ma'lum echimlardan mavhumlik qilishni taklif qilganda, Apache boshqacha yo'l tutdi - ular veb-server va dastur serverlarini iloji boricha birlashtirdilar.

Haqiqatan ham, agar biz dastur serverini umumiy manzil maydonida veb-server moduli sifatida ishlatsak, biz juda sodda sxemani olamiz:

Buning foydasi nimada? Sxema qanchalik sodda va undagi elementlar qancha kam bo'lsa, uni saqlash va saqlash osonroq va arzonroq bo'ladi, nosozliklar soni shunchalik past bo'ladi. Agar bitta server uchun bu unchalik muhim bo'lmasligi mumkin bo'lsa, unda xosting doirasida bu juda muhim omil.

Ikkinchi afzallik - bu ishlash. Shunga qaramay, biz Nginx muxlislarini xafa qilamiz, chunki bitta manzil maydonidagi ish tufayli Apache + mod_php dastur serverining ishlashi har doim boshqa har qanday veb-server + FastCGI (yoki boshqa CGI yechimi) dan 10-20% tezroq bo'ladi. Shuni ham yodda tutish kerakki, sayt tezligi nafaqat dastur serverining ishlashi, balki muqobil veb-serverlar sezilarli darajada yaxshi natijalarni ko'rsatishi mumkin bo'lgan bir qator boshqa shartlar bilan ham bog'liq.

Ammo yana bir jiddiy afzallik bor, bu dastur serverini alohida sayt yoki foydalanuvchi darajasida sozlash qobiliyati. Keling, biroz orqaga qaytsak: FastCGI / CGI sxemalarida dastur serveri alohida xizmat bo'lib, u o'z sozlamalariga ega, hatto boshqa foydalanuvchi yoki boshqa xost nomidan ham ishlashi mumkin. Bitta server ma'muri yoki ba'zi bir yirik loyihalar nuqtai nazaridan bu juda yaxshi, ammo foydalanuvchilar va xosting ma'murlari uchun juda yaxshi emas.

Internetning rivojlanishi mumkin bo'lgan veb-ilovalar (CMS, skriptlar, ramkalar va boshqalar) sonining juda ko'p bo'lishiga olib keldi va kirishning past chegarasi ko'plab odamlarni maxsus texnik bilimga ega bo'lmagan holda sayt qurilishiga jalb qildi. Shu bilan birga, turli xil veb-ilovalar dastur serverining turli xil konfiguratsiyasini talab qilishi mumkin. Qanday bo'lish kerak? Har safar qo'llab-quvvatlash xizmatiga murojaat qilasizmi?

Yechim juda sodda topildi. Ilova serveri endi veb-serverning bir qismi bo'lganligi sababli, uning sozlamalarini boshqarish uchun ikkinchisini topshirishingiz mumkin. An'anaviy ravishda Apache sozlamalarini boshqarish uchun konfiguratsiya fayllaridan tashqari httaccess fayllari ishlatilgan bo'lib, bu foydalanuvchilarga o'z ko'rsatmalarini yozish va ularni ushbu fayl joylashgan katalogga va undan pastroqda, agar u erda sozlamalar ularning httaccess fayli bilan bir-biriga mos kelmasa, qo'llashga imkon beradi. Mod_php rejimida ushbu fayllar ma'lum bir sayt yoki katalog uchun ko'plab PHP parametrlarini o'zgartirishga imkon beradi.

O'zgarishlarni qabul qilish uchun veb-serverni qayta ishga tushirishingiz shart emas va xato bo'lsa, faqat ushbu sayt (yoki uning bir qismi) ishlashni to'xtatadi. Bundan tashqari, hatto tayyor bo'lmagan foydalanuvchilar ham oddiy matnli faylga o'zgartirishlar kiritishi va uni saytdagi papkaga joylashtirishi mumkin va umuman server uchun xavfsizdir.

Ushbu barcha afzalliklarning kombinatsiyasi Apache-ni keng ishlatilishiga va universal veb-server maqomiga ega bo'lishiga olib keldi. Boshqa echimlar tezroq, tejamkor va yaxshiroq bo'lishi mumkin, ammo ular har doim topshiriq uchun moslashtirishni talab qiladilar, shuning uchun ular asosan maqsadli loyihalarda qo'llaniladi, Apache alternativasiz ommaviy segmentda ustunlik qiladi.

Afzalliklar haqida gapirgandan so'ng, kamchiliklarga o'tamiz. Ulardan ba'zilari tanganing boshqa tomoni. Ilova serverining veb-serverning bir qismi ekanligi, ishlashning qulayligi va konfiguratsiyani osonlashtirishi, lekin shu bilan birga bizni xavfsizlik nuqtai nazaridan cheklaydi - dastur server har doim veb-server nomidan ishlaydi va tizimning egiluvchanligida biz qila olmaymiz. veb-serverni va dastur serverini turli xil xostlarga tarqatish, biz skript tilining turli xil versiyalari yoki turli xil sozlamalari bo'lgan serverlardan foydalana olmaymiz.

Ikkinchi ahvolga tushgan narsa - bu resurslarni ko'proq sarflash. CGI sxemasida dastur serveri sahifa yaratadi va veb-serverga beradi, resurslarni bo'shatadi, Apache + mod_php to'plami veb-server mijozga sahifa tarkibini berguncha dastur server resurslarini band qiladi. Agar mijoz sust bo'lsa, unda resurslar uning xizmatining butun muddati davomida band bo'ladi. Shuning uchun tez-tez Nginx tezkor mijoz rolini o'ynaydigan Apache-ning oldiga qo'yiladi, bu Apache-ga tezda sahifadan voz kechish va resurslarni bo'shatish, mijoz bilan o'zaro aloqani yanada tejamli Nginx-ga o'tkazish imkonini beradi.

Xulosa

Bir maqolada zamonaviy texnologiyalarni to'liq qamrab olishning iloji yo'q, shuning uchun biz faqat asosiylariga e'tibor qaratdik, ataylab ba'zi narsalarni sahna ortida qoldirdik, shuningdek muhim soddalashtirishlarga murojaat qildik. Shubhasiz, ushbu sohada ishlashni boshlash uchun sizga mavzuni chuqurroq o'rganish kerak bo'ladi, ammo yangi bilimlarni idrok etish uchun sizga ushbu material bilan asos solishga harakat qilgan ma'lum bir nazariy asos kerak bo'ladi.


Ushbu maqolada veb-serverlarning sxemalarini iloji boricha kengroq tavsiflashga harakat qilaman. Bu sizga serverni tanlashga yordam beradi yoki tez-tez noaniq ko'rsatkichlarga tayanmasdan qaysi arxitektura tezroq bo'lishini hal qiladi.

Umuman olganda - maqola "nima bo'ladi" degan global sharhdir. Raqam yo‘q.

Maqola serverlar bilan ishlash tajribasiga asoslangan holda yozilgan:

  • Apache, Lighttpd, Nginx (Cda)
  • Tomcat, Jetty (Java-da)
  • Twisted (Python)
  • Erlang OTP (Erlang tili)
  • va Linux, FreeBSD operatsion tizimlari

Biroq, printsiplar etarli darajada umumiydir, ular Windows OS, Solaris va boshqa ko'plab veb-serverlarga biron bir shaklda qo'llanilishi kerak.

Veb-serverning maqsadi

Veb-serverning maqsadi oddiy - ko'p miqdordagi mijozlarga bir vaqtning o'zida qo'shimcha qurilmalardan maksimal darajada foydalanish. Buni qanday qilish kerak - bu asosiy muammo va maqolaning mavzusi;)

Aloqalar bilan ishlash

So'rovni qayta ishlash qayerda boshlanadi? Shubhasiz - foydalanuvchidan ulanishni qabul qilishdan.

Buning uchun turli xil operatsion tizimlar turli xil tizim qo'ng'iroqlaridan foydalanadilar. Eng mashhur va ulanishning ko'p sonini sekinlashtiring - tanlang... Keyinchalik samarali bo'lganlar - so'rovnoma, kpoll, epoll.

Zamonaviy veb-serverlar tanlovdan voz kechmoqda.

Operatsion tizimni optimallashtirish

OS yadrosi darajasida optimallashtirish ulanish qabul qilinishidan oldin ham mumkin. Masalan, operatsion tizim yadrosi, ulanishni olgan holda, voqealardan biri sodir bo'lguncha veb-serverni bezovta qilmasligi mumkin.

  • ma'lumotlar kelguniga qadar (ma'lumotlar bazasi)
  • butun HTTP so'rovi kelguniga qadar (http)

Ushbu yozuv paytida ikkala usul ham FreeBSD-da (ACCEPT_FILTER_HTTP, ACCEPT_FITER_DATA) qo'llab-quvvatlanadi va faqat birinchisi Linuxda (TCP_DEFER_ACCEPT) qo'llab-quvvatlanadi.

Ushbu optimallashtirishlar serverga ma'lumotlarni kutish uchun kamroq vaqt sarflashga imkon beradi va shu bilan operatsion samaradorlikni yaxshilaydi.

Ulanish qabul qilindi

Shunday qilib ulanish qabul qilinadi. Endi asosiy vazifa serverning yelkasiga tushadi - so'rovni ko'rib chiqish va tashrif buyuruvchiga javob yuborish. Biz bu erda faqat dinamik ravishda so'rovlarni ko'rib chiqamiz, ular rasmlarni qaytarishdan ko'ra ancha murakkab.

Barcha serverlar asenkron yondashuvdan foydalanadilar.

Bu shundan iboratki, so'rovni qayta ishlash biron bir joyga "chapga" suriladi - u bajarilishi uchun yordamchi jarayon / ipga beriladi va server ishlashda davom etadi va barcha yangi ulanishlarni qabul qiladi va yuboradi.

Amalga oshirilishiga qarab, "ishchi" jarayoni butun natijani serverga qaytarib yuborishi mumkin (keyinchalik mijozga qaytishi uchun), u faqat natija tavsiflovchisini serverga yuborishi mumkin (nusxa olmasdan) yoki natijani mijozning o'ziga qaytarishi mumkin.

Ishchilar bilan ishlashning asosiy strategiyalari

Ishchilar bilan ishlash turli xil usullar bilan birlashtirilishi va har xil natijalarga erishishi mumkin bo'lgan bir nechta elementlardan iborat.

Ishchi turi

Ikkita asosiy turi mavjud - jarayon va ip. Ishlashni yaxshilash uchun ba'zan ikkala tur ham bir vaqtning o'zida ishlatiladi, bir nechta jarayonlar va har birida bir nechta iplar paydo bo'ladi.

Jarayon

Turli xil ishchilar jarayonlar bo'lishi mumkin, bu holda ular bir-biri bilan o'zaro ta'sir qilmaydi va turli ishchilar ma'lumotlari bir-biridan butunlay mustaqil.

Oqim

Iplar, jarayonlardan farqli o'laroq, umumiy, birgalikda ishlatiladigan ma'lumotlar tuzilishiga ega. Ishchining kodida bir xil tuzilmani bir vaqtning o'zida yozish tartibsizlikka olib kelmasligi uchun kirish sinxronizatsiyasi amalga oshirilishi kerak.

Manzil maydoni

Har bir jarayon, shu jumladan server, o'z manzil maydoniga ega bo'lib, undan ma'lumotlarni ajratish uchun foydalanadi.

Server ichida

Server ichida ishlashda ishchi server ma'lumotlariga kirish huquqiga ega. U har qanday tuzilmani o'zgartirishi va turli xil yomon ishlarni qilishi mumkin, ayniqsa xatolar bilan yozilgan bo'lsa.

Afzallik shundaki, ma'lumotlar bir manzil maydonidan boshqasiga o'tkazilishining yo'qligi.

Serverdan tashqarida

Ishchi umuman serverdan mustaqil ravishda ishga tushirilishi va maxsus protokol (masalan, FastCGI) yordamida ishlov berish uchun ma'lumot olishi mumkin.

Albatta, ushbu parametr server uchun eng xavfsiz hisoblanadi. Ammo so'rovni yuborish uchun qo'shimcha ish kerak - bu server va ishchi o'rtasidagi natija.

Ishchining tug'ilishi

Bir vaqtning o'zida ko'plab ulanishlarni boshqarish uchun sizda etarli miqdordagi ishchilar bo'lishi kerak.

Ikkita asosiy strategiya mavjud.

Statika

Ishchilar soni qat'iyan aniqlanishi mumkin. Masalan, jami 20 ta ish oqimi. Agar barcha ishchilar band bo'lsa va 21-so'rov kelib tushsa, server Vaqtinchalik mavjud bo'lmagan kodni beradi - "vaqtincha mavjud emas".

Dinamika

Resurslarni yanada moslashuvchan boshqarish uchun - yukga qarab, ishchilar dinamik ravishda tug'ilishi mumkin. Urug'lantirish ishchilarining algoritmini parametrlash mumkin, masalan (Apache oldingi vilkasi), masalan:

  • Bepul ishchilarning minimal soni \u003d 5
  • Bepul ishchilarning maksimal soni \u003d 20
  • Jami ishchilar \u003d 30 dan oshmaydi
  • Dastlab ishchilar soni \u003d 10

So'rovlar orasida tozalash

Ishchilar so'rovlar orasida o'zlarini qayta boshlashi mumkin, yoki so'rovlarni birma-bir qayta ishlashlari mumkin.

Toza

Har bir so'rovdan oldin u avvalgilarini tozalaydi, ichki o'zgaruvchilarni tozalaydi va hokazo.

Natijada, eski so'rovdan qolgan o'zgaruvchilarni ishlatish bilan bog'liq muammolar va xatolar mavjud emas.

Doimiy

Hech qanday davlat tozaligi yo'q. Natijada resurslarni tejashga erishiladi.

Odatda konfiguratsiyalarni tahlil qilish

Keling, ushbu kombinatsiyalar turli xil serverlar uchun qanday ishlashini ko'rib chiqamiz.

Apache (oldingi vilkalar MPM) + mod_php

Dinamik so'rovlarni qayta ishlash uchun server kontekstida ishlaydigan php moduli ishlatiladi.
  • Jarayon
  • Server ichida
  • Dinamika
  • Toza

Apache (ishchi MPM) + mod_php

Dinamik so'rovlarni qayta ishlash uchun server kontekstida ishlaydigan php moduli ishlatiladi.

Shu bilan birga, php server manzili maydonida ishlaganligi sababli, oqimlar bilan birgalikda foydalaniladigan ma'lumotlar vaqti-vaqti bilan buziladi, shuning uchun to'plam beqaror va tavsiya etilmaydi. Bu PH_ yadrosi va turli xil PHP modullarini o'z ichiga olgan mod_php-dagi xatolar bilan bog'liq.

Moduldagi xato, bitta manzil maydoni tufayli butun serverni ishdan chiqarishi mumkin.

  • Oqim
  • Server ichida
  • Dinamika
  • Toza

Apache (voqea mpm) + mod_php

Event MPM - bu faqat Apache ishlatadigan ishchi strategiyasidir. Hammasi oddiy iplar bilan bir xil, ammo Keep-Alive-ni boshqarish uchun biroz qo'shimchalar mavjud.

Keep-Alive sozlamalari mijoz bir ulanish orqali ko'plab so'rovlarni yuborishi uchun ishlatiladi. Masalan, veb-sahifani va 20 ta rasmni oling. Odatda, ishchi so'rovni ko'rib chiqishni tugatadi - va shu bilan bog'liq qo'shimcha so'rovlar kelib chiqadimi-yo'qmi bir muncha vaqt kutib turadi (tirik qolish vaqti). Ya'ni, bu faqat xotirada saqlanib qoladi.

Event MPM, Keep-Alive-ning barcha so'rovlarini kutishni o'z zimmasiga oladigan qo'shimcha ish zarrachasini yaratadi va ishchini boshqa foydali narsalar uchun ozod qiladi. Natijada, ishchilarning umumiy soni sezilarli darajada kamayadi, chunki hozirda hech kim mijozlarni kutib o'tirmaydi, ammo hamma ishlaydi.

  • Oqim
  • Server ichida
  • Dinamika
  • Toza

Apache + mod_perl

Mod_perl bilan Apache to'plamining o'ziga xos xususiyati Apache so'rovini qayta ishlash jarayonida Perl protseduralariga qo'ng'iroq qilish qobiliyatidir.

Mod_perl server bilan bir xil manzil maydonida ishlaydiganligi sababli, protseduralarini Apache kancalari orqali server ishining turli bosqichlarida ro'yxatdan o'tkazishi mumkin.

Masalan, PerlTransHandler kancasidagi urlni qayta yozib, mod_rewrite bilan bir bosqichda ishlashingiz mumkin.

Quyidagi misolda / example-dan / pass-ga qayta yozish, lekin perl-da tasvirlangan.

Mod_perl yoqilgan Apache konfiguratsiyasida # PerlModule MyPackage :: Misol PerlTransHandler MyPackage :: MyPackage / Example.pm fayl paketidagi misol # MyPackage :: Masalan, Apache :: Constants qw (DECLINED); qat'iy foydalaning; sub handler (my $ r \u003d shift; $ r-\u003e uri ("/ pass") if $ r-\u003e uri \u003d\u003d "/ example" return DECLINED;) 1;

Afsuski, mod_perl o'zi juda og'ir, shuning uchun uni faqat qayta yozish sifatida ishlatish juda qimmat.

Mod_php dan farqli o'laroq, marvarid arpa moduli doimiy, ya'ni har safar o'zini qayta ishga tushirmaydi. Bu juda qulay, chunki u har bir so'rov oldidan katta miqdordagi modulni qayta yuklash zaruratini yo'q qiladi.

  • Jarayon / ip - MPM ga bog'liq
  • Server ichida
  • Dinamika
  • Doimiy

Twisted

Ushbu asenkron server Python-da yozilgan. Uning o'ziga xos xususiyati shundaki, veb-dastur dasturchisining o'zi qo'shimcha ishchilar yaratadi va ularga vazifalar beradi. # serverdagi misol kod # uzun funktsiyani burish, so'rovni qayta ishlash def do_something_big (ma'lumotlar): .... # so'rovni qayta ishlash paytida d \u003d deferToThread(do_something_big, "parametrlar") # natijaga qo'ng'iroqlarni bog'lash.

Bu erda dasturchi so'rovni qabul qilgandan so'ng, deferToThread chaqiruvidan foydalanib, do_something_big funktsiyasini bajarish vazifasi berilgan alohida mavzu yaratadi. Do_something_big muvaffaqiyatli bajarilganda, handleOK funktsiyasi bajariladi, errorElektrda.

Va hozirgi oqim hozirgi vaqtda oddiy ulanishni qayta ishlash bilan davom etadi.

Hamma narsa bitta manzil maydonida sodir bo'ladi, shuning uchun barcha ishchilar, masalan, bir xil qatorni foydalanuvchilar bilan bo'lishishlari mumkin. Shuning uchun Twisted-da ko'p foydalanuvchi chat tipidagi dasturlarni yozish oson.

  • Oqim
  • Server ichida
  • Dinamika
  • Doimiy

Tomkat, Servletlar

Servletlar veb-ilovalarni oqimlashning klassik namunasidir. Bitta Java dastur kodi bir nechta mavzularda ishlaydi. Sinxronizatsiya talab qilinadi va uni dasturchi bajarishi kerak.

  • Oqim
  • Server ichida
  • Dinamika
  • Doimiy

FastCGI

FastCGI - bu veb-server va tashqi ishchilar o'rtasidagi aloqa interfeysi bo'lib, ular odatda jarayon sifatida ishlaydi.Server atrof-muhit o'zgaruvchilarini, sarlavhalarini va so'rovlar tanasini maxsus (HTTP bo'lmagan) formatda yuboradi va ishchi javobni qaytaradi.

Ushbu ishchilarni yumurtlamanın ikki yo'li mavjud.

  1. Server bilan birlashtirilgan
  2. Serverdan ajratish

Birinchi holda, server o'zi tashqi ishchi jarayonlarni yaratadi va ularning sonini boshqaradi.

Ikkinchi holda, ishchi jarayonlarini yumurtalash uchun alohida "spawner" ishlatiladi, ikkinchisi, faqat FastCGI protokoli yordamida aloqa o'rnatadigan va ishchilarni boshqaradigan qo'shimcha server. Odatda spawner ishchilarni iplar sifatida emas, balki jarayonlar sifatida tug'diradi. Dynamics / Static spawner sozlamalari bilan, Pure / Persistent esa ish oqimining xususiyatlari bilan belgilanadi.

FastCGI bilan ishlash usullari

FastCGI bilan ishlashning ikkita usuli mavjud. Birinchi usul eng oson, Apache uni ishlatadi.

so'rovni qabul qilish -\u003e FastCGI-da ishlash uchun yuborish -\u003e javob kuting -\u003e mijozga javob bering.

Ikkinchi usul lighttpd / nginx / litespeed / va boshqalar kabi serverlar tomonidan qo'llaniladi.

so'rovni qabul qilish -\u003e FastCGI-da ishlash uchun yuborish -\u003e boshqa mijozlarni qayta ishlash -\u003e mijoz kelganda unga javob bering.

Belgilangan farq Lighttpd + fastcgi-ga Apache-ga qaraganda samaraliroq ishlashga imkon beradi, chunki Apache jarayoni kutilayotgan paytda Lighttpd-da boshqa ulanishlarga xizmat qilish uchun vaqt bor.

FastCGI ish rejimlari

FastCGI ikki xil ishlash rejimiga ega.
  • Javob beruvchi - odatdagi rejim, qachonki FastCGI so'rov va o'zgaruvchilarni qabul qilsa va javobni qaytarsa
  • Avtorizator - FastCGI javob sifatida kirish huquqini beruvchi yoki rad etadigan rejim. Yopiq statik fayllarni kuzatish uchun qulay

Ikkala rejim ham barcha serverlarda qo'llab-quvvatlanmaydi. Masalan, Lighttpd serverida - ikkalasi ham qo'llab-quvvatlanadi.

FastCGI PHP va PERL

PHP tarjimoni har safar skriptni qayta ishlashdan oldin o'zini tozalaydi, Perl esa so'rovlarni birma-bir quyidagi tsiklda ishlaydi:

Modullarni ulang; while (so'rov keldi) (uni qayta ishlash; javobni chop etish;) Shuning uchun Perl-FastCGI yordamchi modullar bajarilish vaqtining ko'p qismini o'z ichiga olgan joyda ancha samarali bo'ladi.

Xulosa

Maqolada so'rovlarni qayta ishlashning umumiy tuzilishi va ishchilarning turlari muhokama qilingan, bundan tashqari, Apache Event MPM va FastCGI bilan ishlash usullarini ko'rib chiqdik, servlet va Twisted-ni ko'rib chiqdik.

Umid qilamanki, ushbu sharh veb-ilovangiz uchun server arxitekturasini tanlash uchun boshlang'ich nuqta bo'lib xizmat qiladi.

Agar tarmoqqa ulangan kompyuter har kuni ishlatilsa, Internet ham mobil gadjetda ulangan bo'lsa, unda har bir foydalanuvchi vaqti-vaqti bilan "server" so'zini uchratadi. Bundan tashqari, ushbu so'zni turli xil kombinatsiyalarda topish mumkin va har bir foydalanuvchi xavf ostida bo'lgan narsani tushunmaydi. "Server" so'zidan oldin nima yashiringan va nima uchun foydalanuvchilarga bu kerak?

"Server" atamasi apparat qurilmasi va uning dasturiy ta'minotini (apparat va virtual) anglatishi mumkin. Uskuna serveri bu alohida kompyuter. Bu boshqa shaxsiy kompyuterlar va ofis uskunalarining ishlashini ta'minlash uchun kerak. Virtual server bu dasturiy ta'minot. Bunday holda, ma'lum bir server ushbu ikki turni birlashtiradi.

Birinchidan, uning vazifasi tarmoqni boshqarish va foydalanuvchilarni qo'llab-quvvatlashdan iborat ekanligini unutmang. Foydalanuvchilar o'zlariga vazifalarni o'zlari belgilaydilar va bu ularni tezda hal qiladi. Masalan, HP serverlari kabi server qanchalik yaxshi bo'lsa, u o'z vazifalarini shunchalik yaxshi bajaradi.

Ushbu qurilmalarning barchasini bitta tarmoqqa birlashtirmasdan, ko'plab elektron uskunalarga ega bo'lgan yirik kompaniyalarning ishini tasavvur qilish qiyin. Korxonadagi server ofis uskunalarini masofadan boshqarishga imkon beradi va shaxsiy kompyuterlarning bir-biri bilan ishlashiga imkon beradi.

Serverning ishdan chiqishi yoki ishlamay qolishi falokatga olib kelishi mumkin

Korxonalarda serverlar barcha bo'limlarning ishlarini optimallashtirishlari mumkin. Ammo kundalik hayotda biz ko'pincha serverlar ishiga duch kelamiz. Xususan, kassalar va banklardagi kassalar hujjatlarni chop etish va to'lovlarni amalga oshirish uchun serverdan foydalanadilar. Server barcha pochta xabarchilari, ijtimoiy tarmoqlar va aloqa menejerlarining ishini qo'llab-quvvatlaydi.

Server Tarmoqqa kirishni ta'minlaydi. Barcha saytlar serverlarda saqlanadi. Bu virtual xostingni ta'minlaydi. Ushbu xizmat xosting kompaniyalari tomonidan taqdim etiladi.

Buni baham ko'ring