რატომ გჭირდებათ სერვერი, რა ტიპის სერვერები არსებობს. სერვერებთან მუშაობის არატრივიალური შემთხვევები როგორია სერვერის მუშაობის პრინციპი

თუ თქვენ იყენებთ კომპიუტერს, რომელიც დაკავშირებულია ქსელთან ყოველდღე, თუ თქვენი მობილური გაჯეტი ასევე დაკავშირებულია ინტერნეტთან, მაშინ ყველა მომხმარებელი დროდადრო ხვდება სიტყვას "სერვერი". უფრო მეტიც, ეს სიტყვა შეიძლება გამოჩნდეს სხვადასხვა კომბინაციებში და ყველა მომხმარებელს არ ესმის ნათქვამი. რა იმალება სიტყვა "სერვერის" მიღმა და რატომ სჭირდებათ მომხმარებლებს?

ტერმინი "სერვერი" შეიძლება ნიშნავდეს მისთვის აპარატურულ მოწყობილობას და პროგრამულ უზრუნველყოფას (ტექნიკური და ვირტუალური). ტექნიკის სერვერი არის ცალკე კომპიუტერი. ეს საჭიროა სხვა კომპიუტერების და საოფისე აღჭურვილობის მუშაობის უზრუნველსაყოფად. ვირტუალური სერვერი არის პროგრამული უზრუნველყოფა. ამ შემთხვევაში, კონკრეტული სერვერი აერთიანებს ამ ორ ტიპს.

პირველი, რაც უნდა გვახსოვდეს, არის ის, რომ მისი ამოცანაა ქსელისა და მომხმარებლების შენარჩუნება და არა ქსელის მართვა. მომხმარებლები თავად აყენებენ დავალებებს სერვერს და ის სწრაფად აგვარებს მათ. რაც უფრო უკეთესია სერვერი, მაგალითად, როგორიცაა HP სერვერები, მით უფრო კარგად ასრულებს ის თავის მოვალეობებს.

ძნელი წარმოსადგენია მსხვილი კომპანიების მუშაობა, რომლებსაც აქვთ დაყენებული უამრავი ელექტრონული მოწყობილობა, ყველა ამ მოწყობილობის ერთ ქსელში გაერთიანების გარეშე. საწარმოში სერვერი საშუალებას გაძლევთ დისტანციურად მართოთ საოფისე აღჭურვილობა და კომპიუტერებს ერთმანეთთან ურთიერთობის საშუალებას აძლევს.

სერვერის გაუმართაობამ ან გაუმართაობამ შეიძლება გამოიწვიოს კატასტროფა

საწარმოებში სერვერები შესაძლებელს ხდის ყველა განყოფილების მუშაობის ოპტიმიზაციას. მაგრამ ყოველდღიურ ცხოვრებაში ხშირად ვხვდებით სერვერების მუშაობას. კერძოდ, სალაროებში და ბანკებში მთვლელები იყენებენ სერვერს დოკუმენტების დასაბეჭდად და გადახდების შესასრულებლად. სერვერი მხარს უჭერს ყველა მეილერის, სოციალური ქსელის და კომუნიკაციის მენეჯერის მუშაობას.

სერვერი უზრუნველყოფს ინტერნეტთან წვდომას. ყველა საიტი ინახება სერვერებზე. ეს უზრუნველყოფს საერთო ჰოსტინგს. ამ სერვისს ახორციელებენ ჰოსტინგის კომპანიები.

რა არის ვებ სერვერი? ჩვეულებრივი ადამიანის თვალსაზრისით, ეს არის ერთგვარი შავი ყუთი, რომელიც ამუშავებს ბრაუზერის მოთხოვნებს და პასუხად აწარმოებს ვებ გვერდებს. ტექნიკოსი დაგიბომბავთ ბევრი ბუნდოვანი ტერმინით. შედეგად, ახალბედა ვებ სერვერის ადმინისტრატორებს ზოგჯერ უჭირთ ტერმინებისა და ტექნოლოგიების მრავალფეროვნების გაგება. მართლაც, ვებ განვითარების სფერო დინამიურად ვითარდება, მაგრამ ბევრი თანამედროვე გადაწყვეტა ეფუძნება ძირითად ტექნოლოგიებსა და პრინციპებს, რაზეც დღეს ვისაუბრებთ.

თუ არ იცით საიდან დაიწყოთ, მაშინ თავიდან უნდა დაიწყოთ. იმისათვის, რომ არ დაიბნეთ თანამედროვე ვებ ტექნოლოგიების მრავალფეროვნებაში, თქვენ უნდა მიმართოთ ისტორიას, რათა გაიგოთ, სად დაიწყო თანამედროვე ინტერნეტი და როგორ განვითარდა და გაუმჯობესდა ტექნოლოგიები.

HTTP სერვერი

ინტერნეტის განვითარების გარიჟრაჟზე, საიტები წარმოადგენდა სპეციალურად მონიშნული დოკუმენტების და ზოგიერთი დაკავშირებული მონაცემების მარტივ საცავს: ფაილებს, სურათებს და ა.შ. იმისათვის, რომ დოკუმენტებმა შეძლონ ერთმანეთთან და მასთან დაკავშირებულ მონაცემებზე მითითება, შემოთავაზებული იყო ჰიპერტექსტის მარკირების სპეციალური ენა, HTML, და შემოგვთავაზეს HTTP პროტოკოლი ასეთი დოკუმენტების ინტერნეტით წვდომისთვის. ენაც და პროტოკოლიც, განვითარებადი და გაუმჯობესება, დღემდე შემორჩა მნიშვნელოვანი ცვლილებების გარეშე. და ახლახან დაიწყო 1999 წელს მიღებული HTTP/1.1 პროტოკოლის ჩანაცვლება, HTTP/2 პროტოკოლი მოაქვს ფუნდამენტურ ცვლილებებს თანამედროვე ქსელის მოთხოვნების გათვალისწინებით.

HTTP პროტოკოლი დანერგილია კლიენტ-სერვერის ტექნოლოგიის გამოყენებით და მოქმედებს მოქალაქეობის არმქონე მოთხოვნა-პასუხის პრინციპით. მოთხოვნის მიზანი არის გარკვეული რესურსი, რომელიც განისაზღვრება ერთი რესურსის იდენტიფიკატორი - URI (ერთიანი რესურსის იდენტიფიკატორი), HTTP იყენებს URI-ს ერთ-ერთ სახეობას - URL (რესურსების ერთიანი ლოკატორი) - ერთიანი რესურსის ლოკატორი, რომელიც რესურსის შესახებ ინფორმაციის გარდა, განსაზღვრავს მის ფიზიკურ მდებარეობასაც.

HTTP სერვერის ამოცანაა დაამუშაოს კლიენტის მოთხოვნა და მიაწოდოს მას საჭირო რესურსი, ან შეატყობინოს, რომ ამის გაკეთება შეუძლებელია. განვიხილოთ შემდეგი დიაგრამა:

მომხმარებელი, HTTP კლიენტის, ყველაზე ხშირად ბრაუზერის მეშვეობით, ითხოვს გარკვეულ URL-ს HTTP სერვერისგან, სერვერი ამოწმებს და აგზავნის შესაბამის URL ფაილს, ჩვეულებრივ HTML გვერდს. შედეგად მიღებული დოკუმენტი შეიძლება შეიცავდეს ბმულებს დაკავშირებულ რესურსებთან, როგორიცაა სურათები. თუ საჭიროა მათი ჩვენება გვერდზე, მაშინ კლიენტი თანმიმდევრულად ითხოვს მათ სერვერიდან, გარდა სურათებისა, ასევე შეიძლება მოითხოვოს სტილის ფურცლები, კლიენტის მხარეს შესრულებული სკრიპტები და ა.შ. ყველა საჭირო რესურსის მიღების შემდეგ, ბრაუზერი დაამუშავებს მათ HTML დოკუმენტის კოდის მიხედვით და წარუდგენს დასრულებულ გვერდს მომხმარებელს.

როგორც ბევრმა უკვე მიხვდა, ამ სქემაში HTTP სერვერის სახელწოდებით არის ერთეული, რომელიც დღეს უფრო ცნობილია, როგორც ვებ სერვერი. ვებ სერვერის მთავარი მიზანი და ამოცანაა HTTP მოთხოვნების დამუშავება და მათი შედეგების მომხმარებლისთვის დაბრუნება. ვებ სერვერს არ შეუძლია დამოუკიდებლად შექმნას შინაარსი და მუშაობს მხოლოდ სტატიკური შინაარსით. ეს ასევე ეხება თანამედროვე ვებ სერვერებს, მიუხედავად მათი შესაძლებლობების სიმდიდრისა.

დიდი ხნის განმავლობაში, ერთი ვებ სერვერი საკმარისი იყო სრულფასოვანი ვებსაიტის განსახორციელებლად. მაგრამ როგორც ინტერნეტი იზრდებოდა, სტატიკური HTML-ის შესაძლებლობები ძალიან აკლდა. მარტივი მაგალითი: ყოველი სტატიკური გვერდი არის თვითკმარი და უნდა შეიცავდეს ბმულებს მასთან დაკავშირებულ ყველა რესურსთან, როდესაც დაამატებთ ახალ გვერდებს, მათზე ბმულები უნდა დაემატოს არსებულ გვერდებს, წინააღმდეგ შემთხვევაში მომხმარებელი ვერასოდეს შეძლებს მათთან მოხვედრას; .

იმდროინდელი საიტები, ზოგადად, ნაკლებად ჰგავდა თანამედროვეებს, მაგალითად, ქვემოთ მოცემულია რუსულენოვანი ინტერნეტის ერთ-ერთი პიონერის, Rambler კომპანიის საიტის ხედი:

და ნებისმიერ ბმულზე დაწკაპუნებამ შეიძლება ზოგადად დააბნიოს თანამედროვე მომხმარებელი, ასეთი გვერდიდან დაბრუნება შეუძლებელია, გარდა ბრაუზერში ამავე სახელწოდების ღილაკის დაჭერით.

თანამედროვე ვებსაიტის მეტ-ნაკლებად მსგავსის შექმნის მცდელობა ძალიან მალე გადაიზარდა მზარდ სამუშაოდ არსებულ გვერდებზე ცვლილებების შესატანად. ყოველივე ამის შემდეგ, თუ ჩვენ შევცვალეთ რამე საიტის ზოგად ნაწილში, მაგალითად, ლოგო სათაურში, მაშინ ეს ცვლილება უნდა განვახორციელოთ ყველა არსებულ გვერდზე. და თუ ჩვენ შევცვალეთ გზა რომელიმე გვერდისკენ ან წავშალეთ იგი, მაშინ დაგვჭირდება მისი ყველა ბმული მოვძებნოთ და შევცვალოთ ან წავშალოთ ისინი.

ამიტომ, ვებ სერვერების განვითარების შემდეგი ნაბიჯი იყო ტექნოლოგიური მხარდაჭერა სერვერის მხარის გამაძლიერებლები - SSI (სერვერის მხარე მოიცავს). ამან შესაძლებელი გახადა გვერდის კოდში სხვა ფაილების შიგთავსის ჩართვა, რამაც შესაძლებელი გახადა განმეორებადი ელემენტების წაშლა, როგორიცაა სათაური, ქვედა კოლონტიტული, მენიუ და ა.შ. ცალკე ფაილებად და უბრალოდ ჩართეთ ისინი გვერდის საბოლოო შეკრების დროს.

ახლა, ლოგოს ან მენიუს ელემენტის შესაცვლელად, ცვლილებები უნდა განხორციელდეს მხოლოდ ერთ ფაილში, ყველა არსებული გვერდის რედაქტირების ნაცვლად. გარდა ამისა, SSI-მ შესაძლებელი გახადა გვერდებზე გარკვეული დინამიური შინაარსის ჩვენება, მაგალითად, მიმდინარე თარიღი და მარტივი პირობების შესრულება და ცვლადებთან მუშაობა. ეს იყო მნიშვნელოვანი წინგადადგმული ნაბიჯი, რომელიც აადვილებდა ვებმასტერების მუშაობას და აუმჯობესებდა მომხმარებლების კომფორტს. თუმცა, ეს ტექნოლოგიები მაინც არ გვაძლევდა საშუალებას დანერგვა ნამდვილად დინამიური ვებსაიტი.

აღსანიშნავია, რომ SSI დღესაც აქტიურად გამოიყენება, სადაც საჭიროა გარკვეული სტატიკური შინაარსის ჩასმა გვერდის კოდში, უპირველეს ყოვლისა, მისი სიმარტივისა და რესურსებისადმი დაბალი მოთხოვნების გამო.

CGI

ვებ ტექნოლოგიის განვითარების შემდეგი ნაბიჯი იყო სპეციალური პროგრამების (სკრიპტების) გაჩენა, რომლებიც ამუშავებენ მომხმარებლის მოთხოვნებს სერვერის მხარეს. ყველაზე ხშირად ისინი იწერება სკრიპტირების ენებზე, თავდაპირველად ეს იყო Perl, დღეს PHP ფლობს ლიდერობის პალმას. თანდათან გაჩნდა პროგრამების მთელი კლასი - კონტენტის მართვის სისტემები - CMS (კონტენტის მართვის სისტემა), რომელიც წარმოადგენს სრულფასოვან ვებ აპლიკაციებს, რომლებსაც შეუძლიათ მომხმარებელთა მოთხოვნების დინამიური დამუშავება.

ახლა მნიშვნელოვანი წერტილი: ვებ სერვერებმა არ იცოდნენ და არ იციან სკრიპტების შესრულება. აქ სცენაზე გამოდის ახალი ერთეული - აპლიკაციის სერვერი, რომელიც არის სკრიპტირების ენების თარჯიმანი და რომლის დახმარებითაც მუშაობს მათში დაწერილი ვებ აპლიკაციები. DBMS ჩვეულებრივ გამოიყენება მონაცემთა შესანახად, დიდი რაოდენობით ურთიერთდაკავშირებულ ინფორმაციაზე წვდომის აუცილებლობის გამო.

ამასთან, აპლიკაციის სერვერს არ შეუძლია იმუშაოს HTTP პროტოკოლთან და დაამუშავოს მომხმარებლის მოთხოვნები, რადგან ეს არის ვებ სერვერის ამოცანა. მათი ურთიერთქმედების უზრუნველსაყოფად, იგი შემუშავდა საერთო კარიბჭის ინტერფეისი - CGI (საერთო კარიბჭის ინტერფეისი).

ნათლად უნდა გვესმოდეს, რომ CGI არ არის პროგრამა ან პროტოკოლი, ეს არის ზუსტად ინტერფეისი, ე.ი. აპლიკაციებს შორის ურთიერთქმედების გზების ნაკრები. ასევე, ტერმინი CGI არ უნდა აგვერიოს CGI აპლიკაციის ან CGI სკრიპტის კონცეფციასთან, რომელიც აღნიშნავს პროგრამას (სკრიპტს), რომელიც მხარს უჭერს მუშაობას CGI ინტერფეისით.

სტანდარტული შეყვანის/გამოსვლის ნაკადები გამოიყენება მონაცემთა გადასაცემად ვებ სერვერიდან CGI აპლიკაციაში სტდინ, მიიღება უკან stdout, გამოიყენება შეცდომის შეტყობინებების გადასაცემად stderr.

მოდით განვიხილოთ ასეთი სისტემის მუშაობის პროცესი უფრო დეტალურად. მომხმარებლის ბრაუზერიდან მოთხოვნის მიღების შემდეგ, ვებ სერვერი ადგენს, რომ მოითხოვება დინამიური შინაარსი და წარმოქმნის სპეციალურ მოთხოვნას, რომელსაც უგზავნის ვებ აპლიკაციას CGI ინტერფეისის საშუალებით. როდესაც ის მიიღება, აპლიკაცია გადის და აკეთებს მოთხოვნას, რის შედეგადაც მიიღება დინამიურად გენერირებული გვერდის HTML კოდი, რომელიც უბრუნდება ვებ სერვერს, რის შემდეგაც აპლიკაცია გადის.

კიდევ ერთი მნიშვნელოვანი განსხვავება დინამიურ საიტს შორის არის ის, რომ მისი გვერდები ფიზიკურად არ არსებობს იმ ფორმით, რომელიც წარმოდგენილია მომხმარებლისთვის. ფაქტობრივად, არსებობს ვებ აპლიკაცია, ე.ი. სკრიპტებისა და შაბლონების კომპლექტი და მონაცემთა ბაზა, რომელიც ინახავს საიტის მასალებს და სტატიკური შინაარსის ინფორმაციას: სურათები, java სკრიპტები, ფაილები.

მოთხოვნის მიღების შემდეგ, ვებ-აპლიკაცია ამოიღებს მონაცემებს მონაცემთა ბაზიდან და ავსებს მას მოთხოვნაში მითითებული შაბლონით. შედეგი იგზავნება ვებ სერვერზე, რომელიც ავსებს ამ გზით გამომუშავებულ გვერდს სტატიკური შინაარსით (სურათები, სკრიპტები, სტილები) და აგზავნის მომხმარებლის ბრაუზერში. თავად გვერდი არ არის შენახული არსად, გარდა ქეშისა და როდესაც ახალი მოთხოვნა მიიღება, გვერდი ხელახლა გენერირებული იქნება.

CGI-ის უპირატესობები მოიცავს ენობრივ და არქიტექტურულ დამოუკიდებლობას: CGI აპლიკაცია შეიძლება დაიწეროს ნებისმიერ ენაზე და თანაბრად იმუშაოს ნებისმიერ ვებ სერვერთან. სტანდარტის სიმარტივისა და ღიაობის გათვალისწინებით, ამან განაპირობა ვებ აპლიკაციების სწრაფი განვითარება.

თუმცა, უპირატესობების გარდა, CGI-ს აქვს მნიშვნელოვანი უარყოფითი მხარეებიც. მთავარია პროცესის დაწყებისა და შეჩერების მაღალი ზედნადები ხარჯები, რაც იწვევს ტექნიკის რესურსების გაზრდილ მოთხოვნებს და დაბალ შესრულებას. და სტანდარტული I/O ნაკადების გამოყენება ზღუდავს მასშტაბურობას და მაღალ ხელმისაწვდომობას, რადგან ის მოითხოვს, რომ ვებ სერვერი და აპლიკაციის სერვერი იცხოვრონ იმავე სისტემაში.

ამ დროისთვის CGI პრაქტიკულად არ გამოიყენება, რადგან ის შეიცვალა უფრო მოწინავე ტექნოლოგიებით.

FastCGI

როგორც სახელიდან ჩანს, ამ ტექნოლოგიის შემუშავების მთავარი მიზანი იყო CGI მუშაობის გაუმჯობესება. როგორც მისი შემდგომი განვითარება, FastCGI არის კლიენტ-სერვერის პროტოკოლი ვებ სერვერსა და აპლიკაციის სერვერს შორის ურთიერთქმედებისთვის, რაც უზრუნველყოფს მაღალ შესრულებას და უსაფრთხოებას.

FastCGI აღმოფხვრის CGI-ის მთავარ პრობლემას - ვებ აპლიკაციის პროცესის გადატვირთვა თითოეული მოთხოვნისთვის FastCGI პროცესები მუდმივად მიმდინარეობს, რაც საშუალებას გაძლევთ მნიშვნელოვნად დაზოგოთ დრო და რესურსები. მონაცემთა გადასაცემად, სტანდარტული ნაკადების ნაცვლად, ვიყენებთ UNIX სოკეტებიან TCP/IP, რომელიც საშუალებას გაძლევთ განათავსოთ ვებ სერვერი და აპლიკაციის სერვერები სხვადასხვა ჰოსტებზე, რაც უზრუნველყოფს სისტემის მასშტაბურობას და/ან მაღალ ხელმისაწვდომობას.

ჩვენ ასევე შეგვიძლია გავატაროთ რამდენიმე FastCGI პროცესი ერთ კომპიუტერზე, რომელსაც შეუძლია მოთხოვნის პარალელურად დამუშავება ან სკრიპტირების ენის სხვადასხვა პარამეტრები ან ვერსიები. მაგალითად, შეგიძლიათ ერთდროულად გქონდეთ PHP-ის რამდენიმე ვერსია სხვადასხვა საიტებისთვის, რომლებიც მიმართავენ მათ მოთხოვნებს სხვადასხვა FastCGI პროცესებზე.

პროცესების მენეჯერები გამოიყენება FastCGI პროცესების სამართავად და დატვირთვის განაწილების მიზნით, ისინი შეიძლება იყოს ვებ სერვერის ნაწილი ან ცალკეული აპლიკაციები. პოპულარულ ვებ სერვერებს Apache-სა და Lighttpd-ს აქვთ ჩაშენებული FastCGI პროცესების მენეჯერები, ხოლო Nginx მოითხოვს გარე მენეჯერს FastCGI-თან მუშაობისთვის.

PHP-FPM და spawn-fcgi

FastCGI პროცესების გარე მენეჯერები მოიცავს PHP-FPM და spawn-fcgi. PHP-FPM თავდაპირველად იყო PHP-ის პატჩების ნაკრები ანდრეი ნიგმატულინისგან, რომელმაც გადაჭრა რიგი პრობლემები FastCGI პროცესების მართვაში, 5.3 ვერსიიდან დაწყებული, ის არის პროექტის ნაწილი და შედის PHP დისტრიბუციაში. PHP-FPM-ს შეუძლია დინამიურად მართოს PHP პროცესების რაოდენობა დატვირთვის მიხედვით, გადატვირთოს აუზები მოთხოვნების დაკარგვის გარეშე, წარუმატებელი პროცესების გადაუდებელი გადატვირთვა და არის საკმაოდ მოწინავე მენეჯერი.

Spawn-fcgi არის Lighttpd პროექტის ნაწილი, მაგრამ ნაგულისხმევად არ არის ამავე სახელწოდების ვებ სერვერის ნაწილი, Lighttpd იყენებს საკუთარ, უფრო მარტივ პროცესს. დეველოპერები გირჩევენ მის გამოყენებას იმ შემთხვევებში, როდესაც თქვენ გჭირდებათ სხვა ჰოსტზე მდებარე FastCGI პროცესების მართვა, ან გჭირდებათ უსაფრთხოების გაფართოებული პარამეტრები.

გარე მენეჯერები საშუალებას გაძლევთ გამოყოთ თითოეული FastCGI პროცესი საკუთარ chroot-ში (აპლიკაციის root დირექტორიას შეცვლა მის მიღმა წვდომის შესაძლებლობის გარეშე), რომელიც განსხვავდება როგორც სხვა პროცესების chroot-ისგან, ასევე ვებ სერვერის chroot-ისგან. და, როგორც უკვე ვთქვით, საშუალებას გაძლევთ იმუშაოთ სხვა სერვერებზე მდებარე FastCGI აპლიკაციებთან, ლოკალური წვდომის შემთხვევაში, თქვენ უნდა აირჩიოთ წვდომა UNIX სოკეტის საშუალებით, როგორც სწრაფი კავშირი.

თუ კიდევ ერთხელ დავაკვირდებით დიაგრამას, დავინახავთ, რომ გვაქვს ახალი ელემენტი - პროცესის მენეჯერი, რომელიც არის შუამავალი ვებ სერვერსა და აპლიკაციის სერვერებს შორის. ეს გარკვეულწილად ართულებს სქემას, რადგან სერვისების უფრო დიდი რაოდენობა უნდა იყოს კონფიგურირებული და შენახული, მაგრამ ამავე დროს ის ხსნის უფრო ფართო შესაძლებლობებს, რაც საშუალებას გაძლევთ დააკონფიგურიროთ სერვერის თითოეული ელემენტი სპეციალურად თქვენი ამოცანებისთვის.

პრაქტიკაში, ჩაშენებულ მენეჯერსა და გარე მენეჯერს შორის არჩევისას, გონივრულად შეაფასეთ სიტუაცია და შეარჩიეთ ზუსტად ის ინსტრუმენტი, რომელიც საუკეთესოდ შეესაბამება თქვენს საჭიროებებს. მაგალითად, სტანდარტულ ძრავებზე რამდენიმე საიტისთვის მარტივი სერვერის შექმნისას, გარე მენეჯერის გამოყენება აშკარად არასაჭირო იქნება. მიუხედავად იმისა, რომ არავინ აიძულებს თქვენს თვალსაზრისს. Linux-ის კარგი ის არის, რომ ყველას შეუძლია, თითქოს სამშენებლო ნაკრების გამოყენებით, ზუსტად ააწყოს ის, რაც სჭირდება.

SCGI, PCGI, PSGI, WSGI და სხვა

ვებ განვითარების თემაში ჩასვლისას აუცილებლად წააწყდებით ცნობებს სხვადასხვა CGI ტექნოლოგიებზე, რომელთაგან ყველაზე პოპულარული ჩვენ ჩამოვთვალეთ სათაურში. თქვენ შეიძლება დაბნეული იყოთ ასეთი მრავალფეროვნებით, მაგრამ თუ ყურადღებით წაიკითხავთ ჩვენი სტატიის დასაწყისს, მაშინ იცით, როგორ მუშაობს CGI და FastCGI და, შესაბამისად, რომელიმე ამ ტექნოლოგიის გაგება არ გაგიჭირდებათ.

კონკრეტული გადაწყვეტის განხორციელებაში განსხვავებების მიუხედავად, ძირითადი პრინციპები რჩება საერთო. ყველა ეს ტექნოლოგია უზრუნველყოფს კარიბჭის ინტერფეისს ( კარიბჭის ინტერფეისი) ვებ სერვერსა და აპლიკაციის სერვერს შორის ურთიერთქმედებისთვის. კარიბჭეები საშუალებას გაძლევთ გააერთიანოთ ვებ სერვერი და ვებ აპლიკაციის გარემო, რაც საშუალებას გაძლევთ გამოიყენოთ ნებისმიერი კომბინაცია შესაძლო შეუთავსებლობის გარეშე. მარტივად რომ ვთქვათ, არ აქვს მნიშვნელობა თქვენი ვებ სერვერი მხარს უჭერს კონკრეტულ ტექნოლოგიას ან სკრიპტირების ენას, რამდენადაც მას შეუძლია გაუმკლავდეს თქვენთვის საჭირო კარიბჭის ტიპს.

და რადგან ჩვენ უკვე ჩამოვთვალეთ აბრევიატურების მთელი თაიგული სათაურში, მოდით განვიხილოთ ისინი უფრო დეტალურად.

SCGI (მარტივი საერთო კარიბჭის ინტერფეისი) - მარტივი საერთო კარიბჭის ინტერფეისი- შექმნილია როგორც CGI-ის ალტერნატივა და მრავალი თვალსაზრისით FastCGI-ის მსგავსია, მაგრამ უფრო ადვილია განხორციელება. ყველაფერი, რაზეც ვისაუბრეთ FastGCI-სთან დაკავშირებით, ასევე შეესაბამება SCGI-ს.

PCGI (Perl Common Gateway ინტერფეისი) - Perl ბიბლიოთეკა CGI ინტერფეისთან მუშაობისთვის, დიდი ხანია არის მთავარი ვარიანტი Perl აპლიკაციებთან მუშაობისთვის CGI-ის საშუალებით, მას აქვს კარგი შესრულება (რაც შეეხება CGI-ს) რესურსების მოკრძალებული მოთხოვნებით და კარგი გადატვირთვისგან დაცვა.

პსჟი (პერლის ვებ სერვერის კარიბჭის ინტერფეისი) - ვებ სერვერსა და Perl-ის აპლიკაციის სერვერს შორის ურთიერთქმედების ტექნოლოგია. თუ PCGI არის კლასიკური CGI ინტერფეისით მუშაობის ინსტრუმენტი, მაშინ PSGI უფრო მოგაგონებთ FastCGI-ს. PSGI სერვერი უზრუნველყოფს გარემოს Perl აპლიკაციების გასაშვებად, რომელიც მუშაობს უწყვეტად როგორც სერვისი და შეუძლია ვებ სერვერთან კომუნიკაცია TCP/IP ან UNIX სოკეტების საშუალებით და უზრუნველყოფს Perl აპლიკაციებს იგივე უპირატესობებს, როგორც FastCGI.

WSGI (ვებ სერვერის კარიბჭის ინტერფეისი) არის კიდევ ერთი სპეციფიკური კარიბჭის ინტერფეისი, რომელიც შექმნილია ვებ სერვერსა და აპლიკაციის სერვერს შორის ურთიერთქმედებისთვის Phyton ენაზე დაწერილი პროგრამებისთვის.

როგორც ადვილად ხედავთ, ჩვენ მიერ ჩამოთვლილი ყველა ტექნოლოგია, ამა თუ იმ ხარისხით, არის CGI/FastCGI-ის ანალოგები, მაგრამ გამოყენების კონკრეტული სფეროებისთვის. ჩვენ მიერ მოწოდებული მონაცემები საკმაოდ საკმარისი იქნება მათი მოქმედების პრინციპისა და მექანიზმების ზოგადი გაგებისთვის და მათი უფრო ღრმა შესწავლას აზრი აქვს მხოლოდ ამ ტექნოლოგიებთან და ენებთან სერიოზულად მუშაობისას.

განაცხადის სერვერი, როგორც Apache მოდული

თუ ადრე ვსაუბრობდით რომელიმე აბსტრაქტულ ვებ სერვერზე, ახლა ვისაუბრებთ კონკრეტულ გადაწყვეტაზე და ეს არ არის ჩვენი პრეფერენციების საკითხი. ვებ სერვერებს შორის Apache-ს უმრავლეს შემთხვევაში განსაკუთრებული ადგილი უჭირავს, როდესაც ისინი საუბრობენ Linux პლატფორმაზე და მართლაც ვებ სერვერზე, იგულისხმება Apache;

შეიძლება ითქვას, რომ ეს არის ერთგვარი "ნაგულისხმევი" ვებ სერვერი. აიღეთ ნებისმიერი მასიური ჰოსტინგი - Apache იქნება იქ, აიღეთ ნებისმიერი ვებ აპლიკაცია - ნაგულისხმევი პარამეტრები გაკეთებულია Apache-სთვის.

დიახ, ტექნოლოგიური თვალსაზრისით, Apache არ არის ტექნოლოგიის გვირგვინი, მაგრამ ის წარმოადგენს ოქროს შუალედს, ის არის მარტივი, გასაგები, მოქნილი პარამეტრებით და უნივერსალური. თუ თქვენ დგამთ თქვენს პირველ ნაბიჯებს ვებსაიტის მშენებლობაში, მაშინ Apache არის თქვენი არჩევანი.

აქ შეიძლება გაკიცხონ, რომ Apache დიდი ხანია მოძველებულია, ყველა "ნამდვილმა ბიჭმა" უკვე დააინსტალირა Nginx და ა. და ა.შ., ასე რომ, მოდით ავხსნათ ეს წერტილი უფრო დეტალურად. ყველა პოპულარული CMS კონფიგურირებულია Apache-თან გამოსაყენებლად, ეს საშუალებას გაძლევთ მთელი თქვენი ყურადღება გაამახვილოთ ვებ აპლიკაციასთან მუშაობაზე, აღმოფხვრას ვებ სერვერი, როგორც პრობლემების შესაძლო წყარო.

ყველა ფორუმი, რომელიც პოპულარობით სარგებლობს დამწყებთათვის, ასევე იყენებს Apache-ს, როგორც ვებ სერვერს და რჩევების და რეკომენდაციების უმეტესობა კონკრეტულად მასზე ვრცელდება. ამავდროულად, ალტერნატიული ვებ სერვერები ჩვეულებრივ საჭიროებენ უფრო დახვეწილ და ფრთხილ კონფიგურაციას, როგორც ვებ სერვერიდან, ასევე ვებ აპლიკაციიდან. ამავდროულად, ამ პროდუქტების მომხმარებლები, როგორც წესი, ბევრად უფრო გამოცდილი არიან და დამწყებთათვის მათ გარემოში ტიპიური პრობლემები არ განიხილება. შედეგად, შეიძლება შეიქმნას სიტუაცია, როდესაც არაფერი მუშაობს და არავინ არის, ვინც იკითხავს. გარანტირებულია, რომ ეს არ მოხდება Apache-სთან.

სინამდვილეში, რა გააკეთეს Apache-ს დეველოპერებმა, რამაც საშუალება მისცა მათ ჭკუას დაეკავებინა განსაკუთრებული ადგილი? პასუხი საკმაოდ მარტივია: ისინი თავიანთი გზით წავიდნენ. მიუხედავად იმისა, რომ CGI სთავაზობდა აბსტრაქციას კონკრეტული გადაწყვეტილებებისგან და ფოკუსირება უნივერსალურ კარიბჭეზე, Apache-მ ეს სხვაგვარად მოიქცა - მან მაქსიმალურად გააერთიანა ვებ სერვერი და აპლიკაციის სერვერი.

მართლაც, თუ ჩვენ გავუშვით აპლიკაციის სერვერი, როგორც ვებ სერვერის მოდული საერთო მისამართების სივრცეში, მივიღებთ ბევრად უფრო მარტივ სქემას:

რა სარგებელს იძლევა ეს? რაც უფრო მარტივია წრე და რაც უფრო ნაკლებ ელემენტებს შეიცავს, მით უფრო ადვილი და იაფია მისი შენარჩუნება და შენარჩუნება და ნაკლები მარცხის წერტილები აქვს. მიუხედავად იმისა, რომ ეს შეიძლება არც ისე მნიშვნელოვანი იყოს ერთი სერვერისთვის, ჰოსტინგში ეს ძალიან მნიშვნელოვანი ფაქტორია.

მეორე უპირატესობა პროდუქტიულობაა. კიდევ ერთხელ, ჩვენ გაუცრუებ Nginx თაყვანისმცემლებს, ერთი მისამართების სივრცეში მუშაობის წყალობით, Apache + mod_php აპლიკაციის სერვერის მუშაობა ყოველთვის იქნება 10-20% უფრო სწრაფი, ვიდრე ნებისმიერი სხვა ვებ სერვერი + FastCGI (ან სხვა CGI გადაწყვეტა). მაგრამ ასევე უნდა გახსოვდეთ, რომ საიტის სიჩქარე განისაზღვრება არა მხოლოდ აპლიკაციის სერვერის მუშაობით, არამედ რიგი სხვა პირობებით, რომლებშიც ალტერნატიულ ვებ სერვერებს შეუძლიათ მნიშვნელოვნად უკეთესი შედეგების ჩვენება.

მაგრამ არის კიდევ ერთი, საკმაოდ სერიოზული უპირატესობა: აპლიკაციის სერვერის კონფიგურაციის შესაძლებლობა ინდივიდუალური საიტის ან მომხმარებლის დონეზე. მოდით ცოტა უკან დავბრუნდეთ: FastCGI/CGI სქემებში აპლიკაციის სერვერი არის ცალკე სერვისი, თავისი ცალკეული პარამეტრებით, რომელიც შეიძლება იმუშაოს კიდეც სხვა მომხმარებლის სახელით ან სხვა ჰოსტზე. ერთი სერვერის ან რაიმე დიდი პროექტის ადმინისტრატორის თვალსაზრისით, ეს შესანიშნავია, მაგრამ მომხმარებლებისთვის და ჰოსტინგის ადმინისტრატორებისთვის, არც ისე ბევრი.

ინტერნეტის განვითარებამ განაპირობა ის, რომ შესაძლო ვებ აპლიკაციების რაოდენობა (CMS, სკრიპტები, ჩარჩოები და ა. ვებსაიტის განვითარება. ამავდროულად, სხვადასხვა ვებ აპლიკაციებს შეიძლება დასჭირდეთ აპლიკაციის სერვერის განსხვავებული კონფიგურაცია. Რა უნდა გავაკეთო? გჭირდებათ ყოველ ჯერზე დაუკავშირდეთ მხარდაჭერას?

გამოსავალი საკმაოდ მარტივი აღმოჩნდა. ვინაიდან აპლიკაციის სერვერი ახლა არის ვებ სერვერის ნაწილი, შეგიძლიათ დაავალოთ ამ უკანასკნელს მისი პარამეტრების მართვა. ტრადიციულად, Apache-ის პარამეტრების სამართავად, კონფიგურაციის ფაილების გარდა, იყენებდნენ httaccess ფაილებს, რაც მომხმარებლებს საშუალებას აძლევდა დაეწერათ თავიანთი დირექტივები იქ და გამოეყენებინათ ისინი დირექტორიაში, სადაც ეს ფაილი მდებარეობს და ქვემოთ, თუ იქ პარამეტრები არ არის გადაფარული. htaccess ფაილი. mod_php რეჟიმში, ეს ფაილები ასევე საშუალებას გაძლევთ შეცვალოთ მრავალი PHP ვარიანტი ინდივიდუალური საიტისთვის ან დირექტორიასთვის.

ცვლილებების მისაღებად არ გჭირდებათ ვებ სერვერის გადატვირთვა და შეცდომის შემთხვევაში მხოლოდ ეს საიტი (ან მისი ნაწილი) შეწყვეტს მუშაობას. გარდა ამისა, შეუსწავლელ მომხმარებლებსაც კი შეუძლიათ ცვლილებები შეიტანონ მარტივ ტექსტურ ფაილში და განათავსონ იგი საიტზე არსებულ საქაღალდეში და ის მთლიანად სერვერისთვის უსაფრთხოა.

ყველა ამ უპირატესობის ერთობლიობამ მიანიჭა Apache-ს ისეთი ფართო გამოყენება და სტატუსი, როგორც უნივერსალური ვებ სერვერი. სხვა გადაწყვეტილებები შეიძლება იყოს უფრო სწრაფი, უფრო ეკონომიური, უკეთესი, მაგრამ ისინი ყოველთვის საჭიროებენ ამოცანის პერსონალიზაციას, ამიტომ ისინი ძირითადად გამოიყენება მიზნობრივ პროექტებში, დომინირებს მასობრივ სეგმენტში ყოველგვარი ალტერნატივის გარეშე.

უპირატესობებზე რომ ვისაუბრეთ, მოდით გადავიდეთ ნაკლოვანებებზე. ზოგიერთი მათგანი უბრალოდ მონეტის მეორე მხარეა. ის ფაქტი, რომ აპლიკაციის სერვერი არის ვებ სერვერის ნაწილი, იძლევა უპირატესობას შესრულებაში და კონფიგურაციის სიმარტივეში, მაგრამ ამავე დროს გვზღუდავს როგორც უსაფრთხოების თვალსაზრისით - აპლიკაციის სერვერი ყოველთვის მუშაობს ვებ სერვერის სახელით და სისტემის მოქნილობით. ჩვენ არ შეგვიძლია ვებ სერვერის და აპლიკაციის სერვერის გავრცელება სხვადასხვა ჰოსტებზე, ჩვენ არ შეგვიძლია გამოვიყენოთ სერვერები სკრიპტირების ენის სხვადასხვა ვერსიით ან განსხვავებული პარამეტრებით.

მეორე მინუსი არის რესურსების მაღალი მოხმარება. CGI სქემაში აპლიკაციის სერვერი ქმნის გვერდს და აგზავნის მას ვებ სერვერზე, ათავისუფლებს რესურსებს Apache + mod_php კომბინაცია ინახავს აპლიკაციის სერვერის რესურსებს მანამ, სანამ ვებ სერვერი არ დააბრუნებს გვერდის შიგთავსს კლიენტს. თუ კლიენტი ნელია, მაშინ რესურსები დატვირთული იქნება მისი მომსახურების მთელი პერიოდის განმავლობაში. ამიტომ Nginx ხშირად მოთავსებულია Apache-ს წინ, რომელიც ასრულებს სწრაფი კლიენტის როლს, რაც საშუალებას აძლევს Apache-ს სწრაფად მოემსახუროს გვერდს და გაათავისუფლოს რესურსები კლიენტთან ურთიერთქმედების უფრო ეკონომიურ Nginx-ზე გადატანით.

დასკვნა

შეუძლებელია თანამედროვე ტექნოლოგიების მთელი დიაპაზონის ერთ სტატიაში გაშუქება, ამიტომ ჩვენ ყურადღება გავამახვილეთ მხოლოდ მთავარზე, მიზანმიმართულად დავტოვეთ რაღაცები კულისებში და ასევე მივმართეთ მნიშვნელოვან გამარტივებებს. ეჭვგარეშეა, ამ მიმართულებით მუშაობის დაწყებისას, დაგჭირდებათ თემის უფრო ღრმა შესწავლა, მაგრამ ახალი ცოდნის აღქმისთვის საჭიროა გარკვეული თეორიული საფუძველი, რომლის დაგებაც ამ მასალით შევეცადეთ.

შეცდომების კონტროლი კოდის დაწერისას

საიტის მონიტორინგი საძიებო სისტემებში

მომავალი პროექტის ესკიზის შექმნა

ონლაინ სერვისები დიზაინისა და ვებ განვითარების პრობლემების გადასაჭრელად

• სერვერთან მუშაობა

აპაჩი სერვერის ინსტალაცია

დენვერისა და მსგავსი პროგრამების წყალობით, საკმაოდ მარტივი გახდა თქვენს კომპიუტერში ლოკალური სერვერის ინსტალაცია და კონფიგურაცია. ამის შესახებ ბევრი დაიწერა და თავად ინსტალაციის პროცესი ინტუიციურია. მაგრამ თქვენ შეგიძლიათ დააკონფიგურიროთ სერვერი დამხმარე პროგრამული უზრუნველყოფის გარეშე, დააინსტალიროთ მხოლოდ ის, რაც საჭიროა სამუშაოსთვის. ამ სტატიაში ვისაუბრებთ იმაზე, თუ როგორ დააინსტალიროთ Apache სერვერი თქვენს კომპიუტერში და დააკონფიგურიროთ იგი შემდგომი მუშაობისთვის.

PHP-ის ინსტალაცია და კონფიგურაცია

როდესაც Apache სერვერის ინსტალაციასა და კონფიგურაციაზე მთელი სამუშაო დარჩა, შეგიძლიათ დაიწყოთ PHP-ის ინსტალაცია თქვენს კომპიუტერში და დააკონფიგურიროთ იგი შემდგომი მუშაობისთვის.

მონაცემთა ბაზის სერვერის ინსტალაცია და კონფიგურაცია (MySQL)

თუ თქვენ აპირებთ ვებსაიტების შექმნას მონაცემთა ბაზების გამოყენებით (და ეს, სავარაუდოდ, ასეა), მაშინ სრული მუშაობისთვის, Apache-სა და PHP-ის გარდა, დაგჭირდებათ მონაცემთა ბაზის სერვერის ინსტალაცია და კონფიგურაცია - ჩვენს შემთხვევაში ეს არის MySQL. ეს არის ის, რაც ამ სტატიაში იქნება განხილული.

phpMyAdmin-ის ინსტალაცია და კონფიგურაცია

მათთვის, ვინც არ გრძნობს უხერხულობას ბრძანების ხაზის გამოყენებით მონაცემთა ბაზებთან მუშაობისთვის, ასევე მათთვის, ვინც იცის, როგორ მუშაობს მონაცემთა ბაზებთან ბრძანების ხაზის საშუალებით, ეს ნაბიჯი არ არის საჭირო. ყველა დანარჩენისთვის, აქ აღწერილი იქნება ლოკალური სერვერის დაყენების ბოლო ნაბიჯი - ჩვენ დავაინსტალირებთ და დავაკონფიგურირებთ გრაფიკულ გარსს, რომელიც მნიშვნელოვნად შეუწყობს ხელს მონაცემთა ბაზებთან მუშაობას. ჩვენ ვისაუბრებთ phpMyAdmin-ზე.

ჩვენ გამოვაქვეყნეთ ახალი წიგნი სოციალური მედიის კონტენტ მარკეტინგი: როგორ შევიდეთ თქვენი მიმდევრების თავებში და შეაყვაროთ ისინი თქვენი ბრენდი.

ვებ სერვერი არის სერვერი, რომელიც იღებს მომხმარებლის თხოვნებს და პასუხობს მათ - დოკუმენტს, გვერდს ან საიტს.

მეტი ვიდეო ჩვენს არხზე - ისწავლეთ ინტერნეტ მარკეტინგი SEMANTICA-სთან ერთად

ნებისმიერი კომპიუტერი შეიძლება გადაიქცეს სერვერად. ამისათვის თქვენ უნდა დააინსტალიროთ სპეციალური ჭურვი.

ტექნიკური ნაწილის მოთხოვნები განისაზღვრება გამოყოფილი რესურსების რაოდენობით და სიჩქარის მოთხოვნებით. რაც უფრო დიდია ისინი, მით უფრო ძლიერი უნდა იყოს კომპიუტერი.
ამის გასაგებად, მოდი ანალოგია მივცეთ. მიდიხარ ბიბლიოთეკაში და სთხოვ წიგნს მოგცენ. ბიბლიოთეკარი იპოვის შენთვის საჭიროს და გაძლევს. ბიბლიოთეკა არის სერვერი, მასში ინახება ყველა მონაცემი. ბიბლიოთეკარი არის ჭურვი, რომელმაც მიიღო მოთხოვნა და გაგზავნა პასუხი. თქვენ ხართ კლიენტი.
თქვენ შეგიძლიათ გაგზავნოთ ბიბლიოთეკარი დამატებითი ინფორმაციისთვის - ბმულზე დაწკაპუნების მსგავსი. განსხვავება ისაა, რომ ერთი და იგივე რესურსი ინტერნეტში შეიძლება წაიკითხოს შეუზღუდავი რაოდენობის მომხმარებელმა ერთდროულად.
მომხმარებელთა მომსახურება ხორციელდება მსგავსი პრინციპით: როდესაც მოვდივართ წიგნის ასაღებად, შეგვიძლია კითხვა დავუსვათ ბიბლიოთეკარს (საძიებო სისტემა) ან ჩავიხედოთ ინდექსში (Yandex Catalog). ეს დაგეხმარებათ იპოვოთ თქვენთვის საჭირო ინფორმაცია.

რას აკეთებს ვებ სერვერი?

მისი მთავარი ამოცანაა ინფორმაციის შენახვა. გვერდები, ფაილები, სურათები, ტექსტური შინაარსი.
Დავალებები:

• მიიღეთ მოთხოვნები.
• პროგრამების გაშვება სპეციალურ პროგრამირების ენებზე (სერვერი).
• შექმენით ვებ გვერდები.
• გაუგზავნეთ ისინი მომხმარებელს.
• ინფორმაციის დაცვა.
• ვიზიტორთა იდენტიფიცირება.
• შეინახეთ მოთხოვნების ჟურნალი.
• სხვა ტიპის მოთხოვნების მომსახურება: mailto და ა.შ.

იმის გასაგებად, თუ როგორ მუშაობს ვებ სერვერი, თქვენ უნდა გესმოდეთ ქსელში ინფორმაციის გადაცემის პრინციპები. ის ეფუძნება წესებს, რომლებსაც პროტოკოლები ეწოდება: ნებისმიერი URL იწყება ტიპის მითითებით (ftp, http://, https:// და ა.შ.).
Hyper Text Transfer Protocol - გადაცემის პროტოკოლი. საიტის გვერდები ყოველთვის არის ჰიპერტექსტის დოკუმენტის სახით. ეს არის ნებისმიერი სერვერის ან კლიენტის პროგრამის საბოლოო შედეგი.

• როდესაც მომხმარებელი შეაქვს მისამართს ან დააწკაპუნებს ბმულს, ბრაუზერი აკეთებს მოთხოვნას ინფორმაციის კოდირებით ამ წესების მიხედვით.
• ჰოსტი, რომელზეც ეს მისამართია მიბმული, აწარმოებს სერვერის პროგრამებს. თითოეული მათგანი ასრულებს თავის ფუნქციებს.
• მიღებული მონაცემები გაშიფრულია და ბრძანებები სრულდება.
• ჰიპერტექსტი იქმნება, კოდირებულია და უკან იგზავნება.
• ბრაუზერი იღებს პასუხს, აკონვერტებს კოდს html-ად და აჩვენებს გვერდს ეკრანზე.

რა არის საჭირო ვებ სერვერისთვის

ჩვენ გვჭირდება მანქანა, რომელიც დაამუშავებს ყველა მოთხოვნას. შეაფასეთ დატვირთვა, რომელსაც სერვერი უნდა გაუძლოს. ეს დამოკიდებულია ვიზიტორთა რაოდენობაზე: რაც უფრო მეტი მოთხოვნაა, მით მეტი ენერგიაა საჭირო.

არსებობს სპეციალური კომპანიები, რომლებიც უზრუნველყოფენ ჰოსტინგის მომსახურებას. თქვენ ქირაობთ სერვერს. თქვენ გეძლევათ კვოტა საიტის ფაილების ჰოსტინგისთვის.
მაგრამ თუ თქვენ გაქვთ მარტივი ვებსაიტი, მაშინ ამის გაკეთება შეგიძლიათ საკუთარ თავზე.

როდესაც სერვერთან დაკავშირებული პრობლემა მოგვარდება, თქვენ უნდა დააკავშიროთ მას სტატიკური IP მისამართი.

საიტი ხელმისაწვდომი ხდება ვებ სერვერზე დომენის სახელის რეგისტრაციის შემდეგ, მისამართები ითარგმნება DNS სერვისით - აკავშირებს IP მისამართს (მაგალითად, 111.111.111.111) და დომენის სახელს (www.site.com).

ყველაზე გავრცელებული სერვერები

აპაჩი

ეს არის უფასო, თავისუფლად გავრცელებული პროდუქტი, რომელსაც აქვს მრავალი უპირატესობა:

• მუდმივი დეველოპერის მხარდაჭერა.
• სერვერის პროგრამირების ენებთან მუშაობის მოდულები PHP, Perl, Python, Ruby, ASP და ა.შ.
• Საჯარო წყარო. სხვადასხვა პროგრამისტები მონაწილეობენ მოდიფიკაციებში მათი საჭიროებების შესაბამისად. მაგალითად, რუსულენოვანი საზოგადოება მას ადაპტირებს რუსულ დაშიფვრაზე.
• . თავდაპირველად შეიქმნა Unix-ისთვის, მაგრამ ახლა მხარს უჭერს Windows, Mac OS, BSD, Linux, OS/2 და Novell NetWare.
• Უსაფრთხოება.

ინსტალაციის დროს, მიუთითეთ თქვენი ჰოსტის სახელი, მაგალითად, localhost. დააკოპირეთ ნებისმიერი html გვერდი htdocs საქაღალდეში, რომელიც არის Apachex.x საქაღალდეში (სადაც x.x არის ვერსიის ნომერი). ან შექმენით ის Notepad-ში ნებისმიერი ტექსტის შეყვანით და html გაფართოებით შენახვით.

როდესაც ფაილი გამოჩნდება საქაღალდეში, გახსენით თქვენი ბრაუზერი და ჩაწერეთ მისამართი: localhost://PAGE NAME.html. თქვენი ტექსტი გამოჩნდება ეკრანზე - გვერდი იხსნება სერვერიდან. თუ ხედავთ შეცდომას "საიტზე წვდომა არ შემიძლია", ეს ნიშნავს, რომ Apache არ მუშაობს. მისი ხატი უჯრაშია.
დააჭირეთ მასზე და აირჩიეთ "თამაში". ამის შემდეგ ყველაფერი იმუშავებს.

NGNIX

მასზე მოქმედი აქტიური საიტების წილი 21,13%-ია (Netcraft კვლევა). მას ძირითადად იყენებენ მსხვილი კომპანიები და პროფესიონალი დეველოპერები: Yandex, Mail.ru, Rambler და ა.შ. NGNIX უძლებს ვიზიტორთა უზარმაზარ დატვირთვას, არის საიმედო, უსაფრთხო და გააზრებული.
ის თავისუფლად ვრცელდება, მაგრამ გამოჩნდა ფასიანი Plus ვერსიები, რომელთა ღირებულება 2500 დოლარიდან იწყება.

IIS

მის პოპულარობას უზრუნველყოფს დეველოპერის ცნობილი სახელი. ეს არის ვებ სერვისების ნაკრები და ინტეგრირებულია Windows-თან. მშობლიური პროგრამირების პლატფორმა არის ASP.NET, მაგრამ ალტერნატივა, როგორიცაა PHP, შეიძლება განხორციელდეს.

სრული ჰოსტინგი მოითხოვს სერვერის ოპერაციული სისტემის ინსტალაციას Microsoft–დან – Windows Server. მე-6 ვერსია საერთოდ არ იყო განკუთვნილი ჰოსტინგისთვის; ის შეძენილია ავტომატურად ოპერაციულ სისტემასთან ერთად და დამოკიდებულია მის მახასიათებლებზე.

სამონტაჟო პაკეტები

დამწყები პროგრამისტებისთვის და დეველოპერებისთვის იქმნება ინსტრუმენტები, რომლებიც საშუალებას გაძლევთ განათავსოთ ვებ სერვერი თქვენს კომპიუტერში რამდენიმე დაწკაპუნებით.

• OpenServer. პორტატული განვითარების გარემო, რომელიც მოიცავს მრავალ მონაცემთა ბაზას, პროგრამირების ენებს და მათ ვერსიებს, ასევე დამატებით სერვისებს. მაგალითად, ინტერფეისი PhpMyAdmin მონაცემთა ბაზასთან მუშაობისთვის. დღეს ეს არის ყველაზე პოპულარული სამონტაჟო ნაკრები. ის კი მუშაობს ფლეშ დრაივიდან. უფასო ჩამოტვირთვა დაბალი სიჩქარით. 100 რუბლისთვის სიჩქარე მნიშვნელოვნად იზრდება.
• Xampp. აქტიური მხარდაჭერილი პაკეტი: Apache, Php, Perl, MariaDB და ა.შ. აქვს მართვის პანელი. ჩამოტვირთეთ უფასოდ.
• . ყველა საჭირო ხელსაწყოს ძალიან მოსახერხებელი ნაკრები, მათ შორის Apache, PHP, MySQL, PhpMyAdmin. სამწუხაროდ, უახლესი ვერსია მოიცავს მოძველებულ დისტრიბუციებს. ზოგადად, ისინი ასევე შესაფერისია ვარჯიშისთვის. ფორუმის მიხედვით, პროექტი აღარ არის მხარდაჭერილი.

ნებისმიერი მოწყობილობა, მათ შორის სერვერის აღჭურვილობა, ზოგჯერ იწყებს არაპროგნოზირებად მუშაობას. საერთოდ არ აქვს მნიშვნელობა ეს მოწყობილობა ახალია თუ რამდენიმე წელია მუშაობს სრული დატვირთვით.

ბევრია წარუმატებლობისა და არასწორი ოპერაციის შემთხვევები და პრობლემის დიაგნოსტიკა ხშირად მომხიბლავ თავსატეხად იქცევა.

ქვემოთ რამდენიმე საინტერესო და არატრივიალურ შემთხვევებზე ვისაუბრებთ.

Დიაგნოსტიკა

პრობლემის რეგისტრაცია ყველაზე ხშირად ხდება მას შემდეგ, რაც კლიენტები დაუკავშირდნენ ტექნიკურ მხარდაჭერას ბილეთების სისტემის მეშვეობით.

თუ კლიენტი დაგვიკავშირდება და ქირაობს ჩვენგან ფიქსირებული კონფიგურაციის გამოყოფილ სერვერებს, ჩვენ ვატარებთ დიაგნოზს იმის გასარკვევად, რომ პრობლემა არ არის პროგრამული ხასიათის.

კლიენტები ჩვეულებრივ წყვეტენ პროგრამულ პრობლემებს დამოუკიდებლად, თუმცა, ნებისმიერ შემთხვევაში, ჩვენ ვცდილობთ შემოგთავაზოთ დახმარება ჩვენი სისტემის ადმინისტრატორებისგან.

თუ ცხადი გახდება, რომ პრობლემა არის აპარატურა (მაგალითად, სერვერი ვერ ხედავს RAM-ის ნაწილს), მაშინ ამ შემთხვევაში ჩვენ ყოველთვის გვაქვს რეზერვში მსგავსი სერვერის პლატფორმა.

თუ ტექნიკის პრობლემა გამოვლინდა, დისკებს გადავიყვანთ წარუმატებელი სერვერიდან სარეზერვო სერვერზე და ქსელის აღჭურვილობის მცირედი გადაკეთების შემდეგ, სერვერი ამოქმედდება. ამდენად, მონაცემები არ იკარგება და შეფერხების დრო არ აღემატება 20 წუთს დაშვების მომენტიდან.

პრობლემების მაგალითები და გადაწყვეტილებები

ქსელის მარცხი სერვერზე

არსებობს შესაძლებლობა, რომ წარუმატებელი სერვერიდან დისკების სარეზერვო სერვერზე გადატანის შემდეგ, სერვერზე ქსელი შეწყვეტს მუშაობას. ეს ჩვეულებრივ ხდება Linux ოპერაციული სისტემების გამოყენებისას, როგორიცაა Debian ან Ubuntu.

ფაქტია, რომ ოპერაციული სისტემის საწყისი ინსტალაციის დროს ქსელის ბარათების MAC მისამართები იწერება სპეციალურ ფაილში, რომელიც მდებარეობს მისამართზე: /etc/udev/rules.d/70-persistent-net.rules.

როდესაც ოპერაციული სისტემა იწყება, ეს ფაილი ასახავს ინტერფეისის სახელებს MAC მისამართებზე. სერვერის სარეზერვო საშუალებით შეცვლისას, ქსელური ინტერფეისების MAC მისამართები აღარ ემთხვევა, რაც იწვევს სერვერზე ქსელის უფუნქციობას.

პრობლემის გადასაჭრელად, თქვენ უნდა წაშალოთ მითითებული ფაილი და გადატვირთოთ ქსელის სერვისი, ან გადატვირთოთ სერვერი.

ოპერაციული სისტემა, რომელიც ვერ პოულობს ამ ფაილს, ავტომატურად გამოიმუშავებს მსგავსს და შეესაბამება ინტერფეისებს ქსელის ბარათების ახალ MAC მისამართებთან.

ამის შემდეგ არ არის საჭირო IP მისამართების ხელახლა კონფიგურაცია, ქსელი დაუყოვნებლივ დაიწყებს მუშაობას.

მცურავი გაყინვის პრობლემა

ერთ დღეს სერვერი მოვიდა ჩვენთან დიაგნოსტიკისთვის ოპერაციის დროს შემთხვევითი გაყინვის პრობლემა. ჩვენ შევამოწმეთ BIOS და IPMI ჟურნალები - ცარიელია, შეცდომები არ არის. ჩვენ მას ვატარებთ სტრეს-ტესტზე, ვტვირთავთ ყველა პროცესორის ბირთვს 100%-ზე და პარალელურად ვაკვირდებით ტემპერატურას - 30 წუთის მუშაობის შემდეგ გაიყინა.

ამავდროულად, პროცესორი ნორმალურად მუშაობდა, ტემპერატურა არ აღემატებოდა სტანდარტულ მნიშვნელობებს დატვირთვის ქვეშ, ყველა გამაგრილებელი იყო კარგ მდგომარეობაში. გაირკვა, რომ საკითხი არ იყო გადახურებული.

შემდეგი, საჭირო იყო RAM მოდულების შესაძლო წარუმატებლობის გამორიცხვა, ამიტომ სერვერი მეხსიერების ტესტირებაზე გადავიტანეთ საკმაოდ პოპულარული Memtest86+-ის გამოყენებით. დაახლოებით 20 წუთის შემდეგ, სერვერი დაიშალა, როგორც მოსალოდნელი იყო, რამაც გამოიწვია შეცდომები ერთ-ერთ RAM მოდულზე.

მოდული ახლით ჩანაცვლების შემდეგ, ჩვენ კვლავ გამოვცადეთ სერვერი, მაგრამ ფიასკო გველოდა - სერვერი კვლავ გაიყინა, რამაც შეცდომებს წარმოქმნა სხვა RAM მოდული. მათაც შეცვალეს. კიდევ ერთი ტესტი - ის კვლავ გაიყინა, ისევ წარმოქმნის შეცდომებს RAM-ში. ოპერატიული მეხსიერების სლოტების ფრთხილად შემოწმებამ არ გამოავლინა რაიმე დეფექტი.

დარჩა მხოლოდ ერთი შესაძლო დამნაშავე - ცენტრალური პროცესორი. ფაქტია, რომ ოპერატიული მეხსიერების კონტროლერი მდებარეობს პროცესორის შიგნით და სწორედ ამ კონტროლერს შეეძლო მარცხი.

პროცესორის ამოღების შემდეგ, ჩვენ აღმოვაჩინეთ კატასტროფა - სოკეტის ერთი პინი გატეხილი იყო ზედა, ქინძის გატეხილი წვერი ფაქტიურად იყო მიმაგრებული პროცესორის საკონტაქტო ბალიშზე. შედეგად, როდესაც სერვერზე დატვირთვა არ იყო, ყველაფერი ადეკვატურად მუშაობდა, მაგრამ როდესაც პროცესორის ტემპერატურა გაიზარდა, კონტაქტი გაწყდა, რითაც შეჩერდა RAM კონტროლერის ნორმალური მუშაობა, რამაც გამოიწვია გაყინვა.

პრობლემა საბოლოოდ მოგვარდა დედაპლატის შეცვლით, ვინაიდან, სამწუხაროდ, ჩვენ ვერ ვახერხებთ გატეხილი სოკეტის პინის აღდგენას და ეს უკვე სერვის ცენტრის ამოცანაა.

წარმოსახვითი სერვერის გაყინვა OS ინსტალაციის დროს

საკმაოდ სასაცილო შემთხვევები წარმოიქმნება, როდესაც აღჭურვილობის მწარმოებლები იწყებენ ტექნიკის არქიტექტურის შეცვლას, უარს ამბობენ ძველი ტექნოლოგიების მხარდაჭერაზე ახლის სასარგებლოდ.

მომხმარებელი დაგვიკავშირდა საჩივრით სერვერის გაყინვის შესახებ Windows Server 2008 R2 ოპერაციული სისტემის დაყენებისას. ინსტალერის წარმატებით გაშვების შემდეგ, სერვერმა შეწყვიტა რეაგირება მაუსზე და კლავიატურაზე KVM კონსოლში. პრობლემის ლოკალიზაციისთვის, ჩვენ დავუკავშირეთ ფიზიკური მაუსი და კლავიატურა სერვერს - ყველაფერი იგივეა, ინსტალერი იწყებს და წყვეტს პასუხს შეყვანის მოწყობილობებზე.

იმ დროს, ეს სერვერი იყო ერთ-ერთი პირველი, რომელიც გვქონდა Supermicro-ს მიერ წარმოებული X11SSL-f დედაპლატზე დაფუძნებული. BIOS-ის პარამეტრებში იყო ერთი საინტერესო ელემენტი: Windows 7-ის ინსტალაცია, დაყენებული გამორთვა. ვინაიდან Windows 7, 2008 და 2008 R2 განლაგებულია ერთსა და იმავე ინსტალერზე, ჩვენ დავაყენეთ ეს პარამეტრი ჩართვაზე და სასწაულებრივად მაუსი და კლავიატურა საბოლოოდ დაიწყეს მუშაობას. მაგრამ ეს იყო მხოლოდ ეპოსის დასაწყისი ოპერაციული სისტემის დაყენებით.

ინსტალაციისთვის დისკის არჩევის დროს არც ერთი დისკი არ იყო ნაჩვენები, უფრო მეტიც, შეცდომის შესახებ შეტყობინება იყო დამატებითი დრაივერების დაყენების შესახებ. ოპერაციული სისტემა დაინსტალირებული იყო USB ფლეშ დრაივიდან და ინტერნეტში სწრაფმა ძიებამ აჩვენა, რომ ეს ეფექტი ხდება იმ შემთხვევაში, თუ საინსტალაციო პროგრამა ვერ პოულობს დრაივერებს USB 3.0 კონტროლერისთვის.

ვიკიპედიამ იტყობინება, რომ პრობლემა მოგვარებულია BIOS-ში USB 3.0 (XHCI კონტროლერი) მხარდაჭერის გამორთვით. როდესაც დედაპლატისთვის დოკუმენტაცია გავხსენით, სიურპრიზი გველოდა - დეველოპერებმა გადაწყვიტეს მთლიანად დაეტოვებინათ EHCI (Host Controller Interface) კონტროლერი XHCI-ის (eXtensible Host Controller Interface) სასარგებლოდ. სხვა სიტყვებით რომ ვთქვათ, ამ დედაპლატზე ყველა USB პორტი არის USB 3.0 პორტი. ხოლო თუ XHCI კონტროლერს გავთიშავთ, მაშინ გამორთავთ შეყვანის მოწყობილობებსაც, რაც შეუძლებელს გახდის სერვერთან მუშაობას და შესაბამისად ოპერაციული სისტემის დაყენებას.

ვინაიდან სერვერის პლატფორმები არ იყო აღჭურვილი დისკებით CD/DVD დისკების წასაკითხად, პრობლემის ერთადერთი გამოსავალი იყო დრაივერების უშუალოდ ოპერაციული სისტემის დისტრიბუციაში ინტეგრირება. მხოლოდ USB 3.0 კონტროლერის დრაივერების ინტეგრაციით და ინსტალაციის სურათის აღდგენით შევძელით Windows Server 2008 R2-ის დაყენება ამ სერვერზე და ეს შემთხვევა ჩართული იყო ჩვენს ცოდნის ბაზაში, რათა ინჟინრებმა არ დაკარგონ ზედმეტი დრო უშედეგო მცდელობებზე.

კიდევ უფრო სასაცილოა ის შემთხვევები, როცა კლიენტებს მოჰყავთ აღჭურვილობა დასაყენებლად და ის არ იქცევა ისე, როგორც მოსალოდნელია. ეს არის ზუსტად ის, რაც მოხდა Dell PowerVault დისკის თაროების ხაზთან.

მოწყობილობა არის მონაცემთა შენახვის სისტემა ორი დისკის კონტროლერით და ქსელური ინტერფეისით iSCSI პროტოკოლით მუშაობისთვის. ამ ინტერფეისების გარდა, არის MGMT პორტი დისტანციური მართვისთვის.

ჰოსტინგის აღჭურვილობის ჩვენს სერვისებს შორის არის სპეციალური სერვისი "დამატებითი 10 მბიტ/წმ პორტი", რომლის შეკვეთაც შესაძლებელია, თუ საჭიროა დისტანციური სერვერის მართვის ინსტრუმენტების დაკავშირება. ამ თანხებს სხვადასხვა სახელები აქვს:

• "iLO" Hewlett-Packard-ისგან;
• "iDrac" Dell-ისგან;
• IPMI Supermicro-სგან.

მათი ფუნქციონირება დაახლოებით იგივეა - სერვერის სტატუსის მონიტორინგი და დისტანციურ კონსოლზე წვდომა. შესაბამისად, მათ არ სჭირდებათ არხის მაღალი სიჩქარე - კომფორტული მუშაობისთვის საკმაოდ საკმარისია 10 მბიტი/წმ. ეს არის სერვისი, რომელიც შეუკვეთა კლიენტმა. ჩვენ დავაყენეთ შესაბამისი სპილენძის დისტრიბუცია და დავაყენეთ ჩვენი ქსელის აღჭურვილობის პორტი.

სიჩქარის შესაზღუდად, პორტი უბრალოდ კონფიგურირებულია როგორც 10BASE-T და ჩართულია მაქსიმალური სიჩქარით 10 Mbps. მას შემდეგ, რაც ყველაფერი მზად იყო, ჩვენ დავაკავშირეთ დისკის თაროს MGMT პორტი, მაგრამ კლიენტმა თითქმის მაშინვე შეატყობინა, რომ მისთვის არაფერი მუშაობდა.

გადამრთველის პორტის სტატუსის შემოწმების შემდეგ აღმოვაჩინეთ უსიამოვნო შეტყობინება „ფიზიკური ბმული გათიშულია“. ეს შეტყობინება მიუთითებს, რომ არის პრობლემა გადამრთველსა და მასთან დაკავშირებულ კლიენტის აღჭურვილობას შორის ფიზიკურ კავშირთან დაკავშირებით.

ცუდად დაჭიმული კონექტორი, გატეხილი კონექტორი, გატეხილი მავთულები კაბელში - ეს არის პრობლემების მცირე ჩამონათვალი, რომელიც იწვევს კონკრეტულად ბმულის ნაკლებობას. რა თქმა უნდა, ჩვენმა ინჟინრებმა მაშინვე აიღეს გრეხილი წყვილის ტესტერი და შეამოწმეს კავშირი. ყველა მავთული მშვენივრად იყო დაკავშირებული, კაბელის ორივე ბოლო მშვენივრად იყო დაჭიმული. გარდა ამისა, სატესტო ლეპტოპის ამ კაბელთან შეერთებით მივიღეთ კავშირი 10 მბიტ/წმ სიჩქარით, როგორც მოსალოდნელი იყო. გაირკვა, რომ პრობლემა კლიენტის აღჭურვილობის მხარეზე იყო.

იმის გამო, რომ ჩვენ ყოველთვის ვცდილობთ დავეხმაროთ ჩვენს კლიენტებს პრობლემების გადაჭრაში, გადავწყვიტეთ გაგვერკვია კონკრეტულად რა იწვევს ბმულის ნაკლებობას. ჩვენ ყურადღებით განვიხილეთ MGMT პორტის კონექტორი - ყველაფერი რიგზეა.

ჩვენ ვიპოვეთ ორიგინალური ოპერაციული ინსტრუქციები მწარმოებლის ვებსაიტზე, რათა განვმარტოთ, შესაძლებელია თუ არა ამ პორტის „ჩაქრობა“ პროგრამული უზრუნველყოფის მხრიდან. თუმცა, ეს შესაძლებლობა არ იყო გათვალისწინებული - პორტი ნებისმიერ შემთხვევაში ავტომატურად ამაღლდა. იმისდა მიუხედავად, რომ ასეთმა მოწყობილობამ ყოველთვის უნდა უზრუნველყოს Auto-MDI(X) - სხვა სიტყვებით რომ ვთქვათ, სწორად დაადგინეთ რომელი კაბელი არის დაკავშირებული: ჩვეულებრივი თუ კროსოვერი, ექსპერიმენტის გულისთვის, ჩვენ კროსვორდი დავკეცეთ და ჩავრთეთ იგი იმავე გადართვის პორტში. ჩვენ შევეცადეთ აიძულოთ დუპლექსის პარამეტრი გადამრთველ პორტზე. ეფექტი ნულოვანი იყო - ბმული არ იყო და იდეები უკვე ამოიწურა.

აქ ერთ-ერთმა ინჟინერმა გამოთქვა სრულიად საწინააღმდეგო ვარაუდი, რომ მოწყობილობა არ უჭერს მხარს 10BASE-T და იმუშავებს მხოლოდ 100BASE-TX-ზე ან თუნდაც 1000BASE-X-ზე. როგორც წესი, ნებისმიერი პორტი, თუნდაც ყველაზე იაფ მოწყობილობაზე, თავსებადია 10BASE-T-თან და თავდაპირველად ინჟინრის ვარაუდი უარყოფილი იყო, როგორც "მხატვრული", მაგრამ სასოწარკვეთილების გამო მათ გადაწყვიტეს სცადონ პორტის გადართვა 100BASE-TX-ზე.

ჩვენმა გაკვირვებამ საზღვრები არ იცოდა. რა იწვევს ზუსტად 10BASE-T მხარდაჭერის ნაკლებობას MGMT პორტზე, საიდუმლო რჩება. ასეთი შემთხვევა ძალიან იშვიათია, მაგრამ ხდება.

კლიენტი ჩვენზე არანაკლებ გაკვირვებული იყო და ძალიან მადლობელი იყო პრობლემის გადაჭრისთვის. შესაბამისად, მათ დატოვეს პორტი 100BASE-TX-ში, რითაც ზღუდეს სიჩქარე პორტზე უშუალოდ ჩაშენებული სიჩქარის შეზღუდვის მექანიზმის გამოყენებით.

გაგრილების ტურბინის უკმარისობა

ერთ დღეს კლიენტი მოვიდა ჩვენთან და გვთხოვა სერვერის ამოღება და სერვისის ზონაში გადატანა. ინჟინრებმა ყველაფერი გააკეთეს და ტექნიკასთან მარტო დატოვეს. გავიდა ერთი საათი, ორი, სამი - კლიენტი განაგრძობდა სერვერის გაშვებას/შეჩერებას და ჩვენ ვკითხეთ, რა პრობლემა იყო.

აღმოჩნდა, რომ Hewlett-Packard სერვერზე ექვსი გამაგრილებელი ტურბინიდან ორი ჩაიშალა. სერვერი ჩართულია, აჩვენებს გაგრილების შეცდომას და მაშინვე გამორთულია. ამ შემთხვევაში, სერვერი მასპინძლობს ჰიპერვიზორს კრიტიკული სერვისებით. სერვისების ნორმალური ფუნქციონირების აღსადგენად, საჭირო იყო ვირტუალური მანქანების გადაუდებელი მიგრაცია სხვა ფიზიკურ კვანძში.

ჩვენ გადავწყვიტეთ დავეხმაროთ კლიენტს შემდეგი გზით. ჩვეულებრივ სერვერს ესმის, რომ გამაგრილებელი ვენტილატორით ყველაფერი კარგადაა, უბრალოდ რევოლუციების რაოდენობის წაკითხვით. ამავდროულად, რა თქმა უნდა, Hewlett-Packard-ის ინჟინრებმა ყველაფერი გააკეთეს იმისთვის, რომ შეუძლებელი ყოფილიყო ორიგინალური ტურბინის შეცვლა ანალოგიით - არასტანდარტული კონექტორით, არასტანდარტული პინი.

ასეთი ნაწილის ორიგინალი დაახლოებით 100$ ღირს და არ შეიძლება უბრალოდ წახვიდე და იყიდო - ის საზღვარგარეთიდან უნდა შეუკვეთო. საბედნიეროდ, ინტერნეტში აღმოვაჩინეთ ჩართვა ორიგინალური პინუტით და გავარკვიეთ, რომ ერთ-ერთი პინი პასუხისმგებელია წამში ძრავის ბრუნვის რაოდენობის წაკითხვაზე.

დანარჩენი ტექნოლოგიის საკითხი იყო - ჩვენ ავიღეთ რამდენიმე მავთული პროტოტიპისთვის (შემთხვევით ჩვენ ხელთ ვიყავით - ზოგიერთი ჩვენი ინჟინერი დაინტერესებულია Arduino-ზე) და უბრალოდ დავაკავშირეთ მეზობელი სამუშაო ტურბინების ქინძისთავები წარუმატებელი კონექტორებით. . სერვერი დაიწყო და კლიენტმა საბოლოოდ მოახერხა ვირტუალური მანქანების მიგრაცია და სერვისების დაწყება.

რა თქმა უნდა, ეს ყველაფერი გაკეთდა მხოლოდ კლიენტის პასუხისმგებლობით, თუმცა, საბოლოოდ, ასეთმა არასტანდარტულმა სვლამ შესაძლებელი გახადა შეფერხების დროის მინიმუმამდე შემცირება.

სად არის დისკები?

ზოგიერთ შემთხვევაში, პრობლემის მიზეზი ზოგჯერ იმდენად არატრივიალურია, რომ მის პოვნას ძალიან დიდი დრო სჭირდება. ეს არის ის, რაც მოხდა, როდესაც ჩვენს ერთ-ერთ კლიენტს უჩიოდა დისკის შემთხვევითი უკმარისობა და სერვერის გაყინვა. ტექნიკის პლატფორმა - Supermicro 847 შემთხვევაში (4U ფორმის ფაქტორი) გალიებით 36 დისკის დასაკავშირებლად. სერვერზე დაყენებული იყო სამი იდენტური Adaptec RAID კონტროლერი, თითოეულში 12 დისკი იყო დაკავშირებული. როდესაც პრობლემა წარმოიშვა, სერვერმა შეწყვიტა დისკების შემთხვევითი რაოდენობის დანახვა და გაიყინა. სერვერი ამოიღეს წარმოებიდან და დაიწყო დიაგნოსტიკა.

პირველი, რაც ჩვენ მოვახერხეთ, იყო ის, რომ დისკები ცვიოდა მხოლოდ ერთ კონტროლერზე. ამავდროულად, „ჩავარდნილი დისკები“ გაქრა სიიდან მშობლიურ Adaptec-ის მენეჯმენტის პროგრამაში და კვლავ გამოჩნდა იქ მხოლოდ მაშინ, როდესაც სერვერი მთლიანად გამორთული იყო და შემდეგ დაუკავშირდა. პირველი რაც გამახსენდა იყო კონტროლერის პროგრამული უზრუნველყოფა. სამივე კონტროლერს ოდნავ განსხვავებული პროგრამული უზრუნველყოფა ჰქონდა, ამიტომ გადაწყდა ყველა კონტროლერზე ერთი და იგივე პროგრამული უზრუნველყოფის ვერსიის დაყენება. ჩვენ გავაკეთეთ ეს, გავუშვით სერვერი მაქსიმალური დატვირთვის რეჟიმში - ყველაფერი მუშაობს ისე, როგორც მოსალოდნელი იყო. პრობლემის მოგვარების მონიშვნის შემდეგ, სერვერი დაუბრუნდა კლიენტს წარმოებისთვის.

ორი კვირის შემდეგ ისევ იგივე პრობლემა. გადაწყდა კონტროლერის შეცვლა მსგავსით. დავასრულეთ, გავანათეთ, შევაერთეთ, ჩავატარეთ ტესტებზე. პრობლემა დარჩა - რამდენიმე დღის შემდეგ, ახალ კონტროლერზე ყველა დისკი დაეცა და სერვერი უსაფრთხოდ გაიყინა.

ჩვენ ხელახლა დავაინსტალირეთ კონტროლერი სხვა სლოტში, შევცვალეთ საზურგე და SATA კაბელები კონტროლერიდან უკანა პლანზე. ერთი კვირა ტესტირება და ისევ დისკები ამოვარდა - სერვერი ისევ გაიყინა. Adaptec-ის მხარდაჭერასთან დაკავშირებამ შედეგი არ მოიტანა - მათ სამივე კონტროლერი შეამოწმეს და არანაირი პრობლემა არ აღმოაჩინეს. ჩვენ შევცვალეთ დედაპლატა, აღვადგინეთ პლატფორმა თითქმის ნულიდან. ყველაფერი, რაც მცირე ეჭვს იწვევდა, ახლით შეიცვალა. და პრობლემა კვლავ გაჩნდა. მისტიკა და მეტი არაფერი.

პრობლემა მოგვარდა შემთხვევით, როდესაც მათ დაიწყეს თითოეული დისკის ინდივიდუალურად შემოწმება. გარკვეული დატვირთვის ქვეშ, ერთ-ერთმა დისკმა დაიწყო თავის დარტყმა და მოკლე ჩართვა დაიწყო SATA პორტთან, მაშინ როდესაც არ იყო განგაშის მითითება. ამავდროულად, კონტროლერმა შეწყვიტა ზოგიერთი დისკის დანახვა და ხელახლა დაიწყო მათი ამოცნობა მხოლოდ ელექტრომომარაგების ხელახლა ჩართვის შემდეგ. ასე ჩამოაგდო ერთმა წარუმატებელმა დისკმა მთელი სერვერის პლატფორმა.

დასკვნა

რა თქმა უნდა, ეს მხოლოდ მცირე ნაწილია იმ საინტერესო სიტუაციებისა, რომლებიც ჩვენმა ინჟინრებმა მოაგვარეს. ზოგიერთი პრობლემის "დაჭერა" საკმაოდ რთულია, განსაკუთრებით მაშინ, როდესაც არ არის მინიშნება ჩანაწერებში მომხდარი წარუმატებლობის შესახებ. მაგრამ ნებისმიერი ასეთი სიტუაცია ასტიმულირებს ინჟინრებს, რომ დეტალურად გაიგონ სერვერის აღჭურვილობის დიზაინი და იპოვონ პრობლემების მრავალფეროვანი გადაწყვეტილებები.

ეს ის სასაცილო შემთხვევებია, რაც ჩვენს პრაქტიკაში მოხდა.
რომელს შეგხვედრიათ? კეთილი იყოს თქვენი მობრძანება კომენტარებში.