გამარჯობა...
ალბათ ყველა ხართ ინფორმირებული biletebi.ge -ს პრობლემის შესახებ...
კარგი იქნება განვიხილოთ ეს საკითხი და უფრო მომზადებულად შევხვდეთ მსგავს პრობლემებს თუ ისენი ოდესმე შეგვექმნება...
მე დავწერ ჩემს მოსაზრებებს, თქვენც მიამატეთ / მოაკელით თქვენი შეხედულებისამებრ...
ნებისმიერი საიტის ფუნქციონირებისათვის საჭიროა რესურსები, ეს რესურსები ძირითადად სამ კატეგორიად შეგვიძლია დავყოთ:
1) პროცესორული რესურსები - CPU
2) მყარი დისკი - HDD
3) ქსელური რესურსები - ინტერნეტი (გლობალური ქსელი)ეს ძირითადი რესურსი კრიტიკულად მნიშვნელოვანია ყველა საიტისათვის, განვიხილოთ რა მნიშვნელობა აქვთ მათ და რა
"კრიტიკულ" როლს თამაშობენ:
1) CPU პასუხისმგებელია იმაზე რომ ინფორმაცია დამუშავდეს და რომელიმე
კონკრეტულ პროგრამას (მაგალითად apache ვებ სერვერს) დამუშავებული ინფორმაცია მიეწოდოს რაც
შეიძლება სწრაფად...
2) მყარი დისკი არის ადგილი სადაც განთავსებულია ფაილები, იქნება ეს
დინამიურად გენერირებადი კონტენტის სკრიპტები (მაგალითად PHP) თუ სტატიკურად მისაწოდებელი
HTML, JS, CSS, PNG და ასე შემდეგ ფაილები. თუ ვებ სერვერი ვერ ახდენს ინფორმაციის სწრაფად
წაკითხვას საიტი იქნება შენელებული... სტატიკური ფაილების მიწოდება არ არის დიდი პრობლემა, მათი
ოპერატიულ მეხსიერებაში შენახვაც არის შესაძლებელი (ოპერატიული მეხსიერება გაცილებით სწრაფია
თუნდაც ყველაზე საუკეთესო SSD ვინჩესტერებზე)... მაგრამ HDD -ს ყველაზე კრიტიკულიი მომენტი მაშინ
დგება როცა მონაცემთა ბაზიდან ინფორმაციის წაკითხვა ან მასში ინფორმაციის შენახვაა საჭირო... რაც
მეტ ხანს დაიგვიანებს ბაზა პასუხს მით უფრო გაიწელება საიტის ჩატვირთვის დრო...
3) ქსელური რესურსები საჭიროა იმისათვის რომ საიტთან დაკავშირება მოხდეს.
რაც უფრო კარგი ქსელია მით უფრო სწრაფად და მრავლად ხდება მოთხოვნის დაკმაყოფილება. სწრაფად
ნიშნავს იმას რომ ინფორმაციის ჩატვირთვა მომხმარებლისათვის ხდება მაღალი სიჩქარით და მრავლად
ნიშნავს რომ ამ სიჩქარეს სერვერი ინარჩუნებს მომხმარებელთა რაოდენობრივი ზრდის დროსაც.
განვიხილოთ ეხლა ყველა ეს დეტალი ბოლოდან:
3) ინტერნეტ რესურსები: როგორც ყველა რესურსი ინტერნეტ დაკავშირების რესურსიც შეზღუდულია, მას არ შეუძლია
შეუზღუდავად დიდი რაოდენობის ინფორმაციის გატარება. როგორც წესი არსებობს 100 mb -იანი, 1,000
mb -იანი (იგივე 1GB-იანი) და 10 GB-იანი ინტერნეტ არხები (სხვა არხებიც არსებობს, მაგრამ აქ არ არის
მაგაზე საუბარი). თუ რაიმე ფორმით მოხდა რესურსის ამოწურვა, ან რეალური საფრთხის წინაშე დადგა
სისტემა რომ შეიძლება რესურსების ლიმიტს მივაღწიოთ - შეიძლება მივმართოთ რამოდენიმე მეთოდს:
ა) შეგვიძლია გამოვიყენოთ ე.წ. ლინკების აგრეგაცია (ბონდირება). ეს არის მეთოდი, რომლის დროსაც
ფიზიკურ აპარატურას უმონტაჟდება დამატებითი ქსელური მოწყობილობები (ქსელის კარტა), კაბელებით
ყველა ამ ქსელურ კარტებზე ხდება ინტერნეტის (ქსელის) მიერთდება და შემდეგ ოპერაციული სისტემის
შესაბამისად ხდება ყველა ამ კაბელის ერთ IP მისამართში გაერთიანება.... ადვილი მისახვედრია რომ 4
ქსელის კარტის დამატებით რესურსები გაოთხმაგდება.
ბ) შეგვიძლია გავაკეთოთ ე.წ. dns -ის round robin -ით მანიპულირება და საიტი ითარგმნებოდეს
ხდებოდეს მისი resolve) არა ერთ IP მისამართში, არამედ რამოდენიმეში და თითოეულ მათგანზე იყოს
ზუსტი ასლი საიტებისა. მაგალითად საიტი xoks.net ამჟამად ითარგმნება როგორც მისამართი 80.241.252.86,
შეგვიძლია გავაკეთოთ ისე, რომ ის ითარგმნებოდეს დამატებით ორ, სამ, ოთხ ან მეტ IP მისამართში,
როგორც მაგალითად ეს ხდება google.com -ის შემთხვევაში
173.194.32.136
173.194.32.133
173.194.32.130
173.194.32.135
173.194.32.128
173.194.32.129
173.194.32.137
173.194.32.134
173.194.32.131
173.194.32.132
173.194.32.142
აქ თითოეული IP-ის მიღმა შეიძლება კლასტერები იყოს, ბონდირებული სისტემები 4 და მეტი ლინკებით
და ასე შემდეგ.
2) მყარი დისკები: მყარი დისკების წარმადობის ზრდა შეიძლება მოხდეს თვითონ ფიზიკური მოწყობილობის ხარჯზე,
მაგალითად რეგულარული SATA ვინჩესტერებიდან შეგვიძლია გადავიდეთ SAS -ზე, რომელიც 7200
RPM-იდან (დისკის ბრუნვის სისწრაფე) გადაგვიყვანს 10,000 ან 15,000 -ზე, ასევე შეგვიძლია SSD
ვინჩესტერებითაც გავზარდოთ წაკითხვა / ჩაწერის სისწრაფე, SSD -ები რომელიც PCI კარტებით
უკავშირდებიან motherboard-ს გამოირჩევიან სუპერ სისწრაფით. გარდა ვინჩესტერების
(ასე მოვიხსენიებთ ხოლმე მყარს დისკებს) ფიზკური სისწრაფისა (და წარმადობისა) შესაძლებელია მათი
რაოდენობრივი ურთიერთდაკავშირება და ამის ხარჯზე სისწრაფის, წარმადობის და უსაფრთხოების ზრდა.
სისწრაფე ნიშნავს როცა ინფორმაცია სწრაფად ბრუნდება (ან ინახება), წარმადობა ნიშნავს როცა
სისწრაფე შენარჩუნებულია მოთხოვნის ზრდის დროსაც და უსაფრთხოება ნიშნავს როცა ინფორმაცია
დაცულია განადგურებისა ან დაზიანებისაგან. აღნიშნულ მეთოდს (მყარი დისკების რაოდენობრივ
ურთიერთდაკავშირებას) ეწოდება RAID. ეს უკანასკნელი რამოდენიმე მეთოდს გულისხმობს, მათ შორის:
RAID 0 - არის როდესაც ორი ვინჩესტერი ერთმანეთთან ისეა დაკავშირებული რომ შესანახი ინფორმაცია
(მაგალითად ფაილი) იყოფა ორ ნაწილად და თითოეული ინახება სხვადასხვა ვინჩესტერზე. სისტემა
აღიქვამს როგორც ერთ ვინჩესტერს. აღნიშნული მიდგომის პრობლემა იმაში მდგომარეობს რომ
რომელიმე დისკის მწყობრიდან გამოსვლის შემთხვევაში ინფორმაცია გამოუყენებელი ხდება მეორე
ვინჩესტერშიც... ამ მეთოდის ძირითადი დამახასიათებელია ოპერაციის (ჩაწერა / წაკითხვა ) სისწრაფე
(რადგან ოპერაცია სრულდება არა ერთი ვინჩესტერის რესურსით არამედ ორით)
RAID 1 - ეს მიდგომა გულისხმობს რომ ორი ვინჩესტერი ერთმანეთთან დაკავშირებულია და თითოეული
ფაილი კოპირებულია მეორე დისკზე, სისტემა ხედავს როგორც ერთ დისკს. აღნიშნული მიდგომის
პრობლემატურობა იმაში მდგომარეობს რომ მეორე ვინჩესტერი საერთოდ არ ჩანს, ის ე.წ. სარეზერვო
როლს ასრულებს და მხოლოდ მაშინ ხდება მისი გამოყენება როცა პირველი პრობლემის გამო
მწყობრიდან გამოვა. ამ მეთოდის ძირითადი დამახასიათებელია ინფორმაციის უსაფრთხოება.
RAID 10 - მიდგომა არის RAID 1 -ისა და RAID 0 -ის კომბინაცია, ორი ვინჩესტერი RAID 1 -ია
გაერთიანებული და ეს "ერთი" ვინჩესტერი დაწყვილებულია ( RAID 0 -ით) დანარჩენ მეთოდებს არ ავხსნი,
საკმარისზე მეტი ვიდეოებია ინტერნეტში მათ შესახებ.
არსებობს კიდევ ისეთი მიდგომა ვინჩესტერების წარმადობის ზრდის როგორიც არის storage cluster-ები,
შესაძლებლია სხვადასხვა სისტემის (ფიზიკური სერვერის) ურთიერთდაკავშირება ისე, რომ ინფორმაციის
შენახვა ხდებოდეს დინამიურად, გადანაწილებული სხვადახვა მანქანაზე. არსებობს NAS / SAN ტიპის
storage კლასტერები. მათ შორის ძირითადი განსხვავება ის არის რომ ერთი (NAS) ქსელურად ახდენს
სტორიჯების დაკავშირებას (ჩვეულებრივი ქსელის კაბელებით, სპეციალური რესურსის მეშვეოებით,
სპეციალური სერვისით - მაგალითად NFS) ხოლო SAN -ის შემთხვევაში ხდება კლასტერების სპეციალური
კარტით მიერთება motherboard -ზე (SAN -ები იმდენ ახსნას მოითხოვს შეიძლება ერთი წელი მოვუნდეთ
წერა-კითხვას
)
1) პროცესორული რესურსები
პროცესორული რესურსების ზრდა შეიძლება როგორც ფიზიკურად, სერვერში პროცესორის დამატებით
(როგორც წესი სერვერს ორი პროცესორის შესაძლებლობა აქვს - ან მეტის), მისი შენაცვლებით (როცა
ვცვლით ან პროცესორს უფრო უკეთესით ან თვითონ სერვერს უფრო სწრაფი პროცესორით) ან შეიძლება ისე
გაკეთდეს რომ პროცესორები სხვადასხვა საჭიროებისათვის დაწყვილდნენ და რაიმე სამუშაო ჩაატარონ
ერთად (მაგალითად ვიდეო rendering -ისთვის). პროცესორების დაწყვილება საკმაოდ კომპლექსური
საკითხია, ძირითადი იდეა იმაში მდგომარეობს რომ ცენტრალური დავალების მიმღები დასამუშავებელ
ინფორმაციას ანაწევრებს მასთან დაკავშირებულ სხვადასხვა სერვერზე და ინფორმაციასაც შესაბამისად
აგროვებს. ყველაზე გავრცელებული, მოქნილი და მოხერხებული მეთოდი პროცესორული რესურსების
ზრდისტვის (და მისი transparent scalability -ისთვის - ანუ იმისთვის რომ რესურსების მოცულობის ზრდა
იყოს მაქსიმალურად გამჭვირვალე, შეუმჩნეველი, უმტკივნეულო) იყენებენ ე.წ. cloud -ს, ღრუბლოვან
რესურსებს, სადაც პროცესორული რესურსები ერთმანეთთან დაკავშირებულია (სხვადასხვა ფიზიკური
მოწყობილობების, სერვერების ხარჯზე) და იძლევიან ერთიან, მთლიან რესურსს.... საკუთარი, private
ღრუბლოვანი სერვისის შექმნა ძალიან დიდ ცოდნასაც მოითხოვს და რესურსებსაც (ფიზიკური
მოწყობილობების შეძენას, სერვერების განსათავსებელ ადგილს - დატა ცენტრს, ინტერნეტ კავშირს,
მუდმივ და სტაბილურ დენს, გაგრილებას სერვერების, ასევე storage server-ები, network routers,
switches და ათასი სხვა რამეც), მაგრამ არსებობს სერვისები რომელიც უზრუნველყოფენ ამ cloud
service-ების გაქირავებას. ანუ თქვენ დინამიურად მზარდი რესურსი შეგიძლიათ იქირავოთ ისე, რომ არ
გქონდეთ შიში ლიმიტისა. ყველაზე გავრცელებული cloud service -ები რომელიც მე ვიცი google cloud და
ჩემი საყვარელი amazon AWS -ია.
პრობლემის სწრაფად მოგვარებისათვის მე მოვიქცეოდი ასე:
საიტის NS-ებს სასწრაფოდ გავიტანდი cloudflare -ზე, შევიძენდი მათ DDoS shield -ს, ჩავრთავდი იქაურ ქეშირებას, თუ პრობლემა
არ მოგვარდებოდა სასწრაფო წესით გადავაწყობდი სისტემას ამაზონის AWS-ზე, დინამიურად გავუზრდიდი პროცესორული რესურსების რაოდენობას, მყარ დისკებს და სერვისს ისევ დავტოვებდი cloudflare-ზე...
პრობლემის მაინც არსებობის შემთხვევაში მონაცემთა ბაზას შევუქმნიდი ახალ instance -ს (ანუ ცალკე სისტემას), მასაც გავუზრდიდი მოცულობას მაქსიმუმამდე და კოდში განვახორციელებდი ცვლილებას რომ ბაზა აღარ ყოფილიყო ლოკალურ-სისტემური, არამედ გარე სერვისთან მომხდარიყო დაკავშირება...
ღრმად ვარ დარწმუნებული ეს მიდგომა მოაგვარებდა პრობლემას თუნდ არაოპტიმალურად ყოფილიყო საიტი დაწერილი...
მაქსიმალურად ვეცადე პოსტი მოკლე და აბსტრაქტული ყოფილიყო, არ გამოსულიყო ის მიბმული
რომელიმე სისტემას (მაგალითად GNU / Linux -ს), რა გამომივიდა - თქვენ შეაფასეთ....
პრობლემის სწრაფად მოგვარებისათვის მე მოვიქცეოდი ასე:
საიტის NS-ებს სასწრაფოდ გავიტანდი cloudflare -ზე, შევიძენდი მათ DDoS shield -ს, ჩავრთავდი იქაურ ქეშირებას, თუ პრობლემა
არ მოგვარდებოდა სასწრაფო წესით გადავაწყობდი სისტემას ამაზონის AWS-ზე, დინამიურად გავუზრდიდი პროცესორული რესურსების რაოდენობას, მყარ დისკებს და სერვისს ისევ დავტოვებდი cloudflare-ზე...
პრობლემის მაინც არსებობის შემთხვევაში მონაცემთა ბაზას შევუქმნიდი ახალ instance -ს (ანუ ცალკე სისტემას), მასაც გავუზრდიდი მოცულობას მაქსიმუმამდე და კოდში განვახორციელებდი ცვლილებას რომ ბაზა აღარ ყოფილიყო ლოკალურ-სისტემური, არამედ გარე სერვისთან მომხდარიყო დაკავშირება...
ღრმად ვარ დარწმუნებული ეს მიდგომა მოაგვარებდა პრობლემას თუნდ არაოპტიმალურად ყოფილიყო საიტი დაწერილი...
This post has been edited by Svani91 on 24 Jun 2015, 16:05 
biletebi.ge -ს პრობლემა და მისი მოგვარების გზები, hardware / software scaling
