របៀបដែល Badoo សម្រេចបាននូវសមត្ថភាពក្នុងការបង្ហាញរូបភាព 200k ក្នុងមួយវិនាទី

គេហទំព័រទំនើបគឺស្ទើរតែមិននឹកស្មានដល់ដោយគ្មានមាតិកាប្រព័ន្ធផ្សព្វផ្សាយ៖ ស្ទើរតែគ្រប់ជីដូនទាំងអស់មានស្មាតហ្វូន គ្រប់គ្នានៅលើបណ្តាញសង្គម ហើយពេលវេលារងចាំក្នុងការថែទាំគឺមានតម្លៃសម្រាប់ក្រុមហ៊ុន។ នេះគឺជាប្រតិចារិកនៃដំណើររឿងរបស់ក្រុមហ៊ុន Badoo អំពីរបៀបដែលនាងរៀបចំការចែកចាយរូបថតដោយប្រើដំណោះស្រាយផ្នែករឹង បញ្ហាដំណើរការអ្វីដែលនាងបានជួបប្រទះនៅក្នុងដំណើរការ មូលហេតុដែលបណ្តាលឱ្យពួកគេ និងរបៀបដែលបញ្ហាទាំងនេះត្រូវបានដោះស្រាយដោយប្រើដំណោះស្រាយកម្មវិធីផ្អែកលើ Nginx ខណៈពេលដែលធានានូវភាពអត់ធ្មត់ចំពោះកំហុសនៅគ្រប់កម្រិត (видео) យើងសូមអរគុណដល់អ្នកនិពន្ធរឿងរបស់ Oleg សាន់នីស Efimova និង Alexandra Dymova ដែលបានចែករំលែកបទពិសោធន៍របស់ពួកគេនៅក្នុងសន្និសីទ ការងារថ្ងៃ 4.

— សូមចាប់ផ្តើមជាមួយនឹងការណែនាំបន្តិចបន្តួចអំពីរបៀបដែលយើងរក្សាទុក និងឃ្លាំងសម្ងាត់រូបថត។ យើង​មាន​ស្រទាប់​មួយ​ដែល​យើង​ទុក​វា ហើយ​ស្រទាប់​មួយ​ដែល​យើង​ទុក​រូបថត។ ក្នុងពេលជាមួយគ្នានេះ ប្រសិនបើយើងចង់សម្រេចបាននូវអត្រាល្បិចខ្ពស់ និងកាត់បន្ថយការផ្ទុកនៅលើការផ្ទុក វាជារឿងសំខាន់សម្រាប់យើងដែលរូបថតនីមួយៗរបស់អ្នកប្រើប្រាស់ម្នាក់ៗស្ថិតនៅលើម៉ាស៊ីនមេឃ្លាំងសម្ងាត់មួយ។ បើមិនដូច្នេះទេ យើងនឹងត្រូវដំឡើងថាសច្រើនជាងនេះច្រើនដង ដោយសារយើងមានម៉ាស៊ីនមេច្រើន។ អត្រាល្បិចរបស់យើងគឺប្រហែល 99% ពោលគឺយើងកំពុងកាត់បន្ថយការផ្ទុកនៅលើការផ្ទុករបស់យើង 100 ដង ហើយដើម្បីធ្វើដូច្នេះកាលពី 10 ឆ្នាំមុន នៅពេលដែលអ្វីៗទាំងអស់នេះកំពុងត្រូវបានសាងសង់ យើងមានម៉ាស៊ីនមេចំនួន 50 ។ ដូច្នេះហើយ ដើម្បីបម្រើរូបថតទាំងនេះ យើងត្រូវការដែនខាងក្រៅចំនួន 50 ដែលម៉ាស៊ីនមេទាំងនេះបម្រើ។

ជាធម្មតា សំណួរបានកើតឡើងភ្លាមៗ៖ ប្រសិនបើម៉ាស៊ីនមេរបស់យើងមួយធ្លាក់ចុះ ហើយមិនអាចប្រើបាន តើយើងបាត់បង់ផ្នែកណានៃចរាចរណ៍? យើងបានក្រឡេកមើលអ្វីដែលមាននៅលើទីផ្សារ ហើយសម្រេចចិត្តទិញផ្នែករឹងមួយ ដើម្បីឱ្យវាអាចដោះស្រាយបញ្ហាទាំងអស់របស់យើង។ ជម្រើសបានធ្លាក់ទៅលើដំណោះស្រាយរបស់ក្រុមហ៊ុនបណ្តាញ F5 (ដែលថ្មីៗនេះបានទិញ NGINX, Inc): BIG-IP Local Traffic Manager ។

អ្វីដែលផ្នែករឹងនេះ (LTM) ធ្វើ៖ វាគឺជារ៉ោតទ័រដែកដែលធ្វើអោយមានជាតិដែកនៃច្រកខាងក្រៅរបស់វា ហើយអនុញ្ញាតឱ្យអ្នកបញ្ជូនចរាចរដោយផ្អែកលើបណ្តាញ topology លើការកំណត់មួយចំនួន និងធ្វើការត្រួតពិនិត្យសុខភាព។ វាមានសារៈសំខាន់សម្រាប់យើងដែលផ្នែករឹងនេះអាចត្រូវបានសរសេរកម្មវិធី។ ដូច្នោះហើយ យើងអាចពណ៌នាអំពីតក្កវិជ្ជាអំពីរបៀបដែលរូបថតរបស់អ្នកប្រើប្រាស់ជាក់លាក់មួយត្រូវបានបម្រើពីឃ្លាំងសម្ងាត់ជាក់លាក់មួយ។ តើវាមើលទៅដូចអ្វី? មានផ្នែកមួយនៃផ្នែករឹងដែលមើលលើអ៊ីនធឺណិតនៅលើដែនមួយ IP មួយមិនផ្ទុក ssl ញែកសំណើ http ជ្រើសរើសលេខឃ្លាំងសម្ងាត់ពី IRule កន្លែងដែលត្រូវទៅ និងអនុញ្ញាតឱ្យចរាចរណ៍ទៅទីនោះ។ ក្នុងពេលជាមួយគ្នានេះ វាធ្វើការត្រួតពិនិត្យសុខភាព ហើយក្នុងករណីដែលម៉ាស៊ីនមួយចំនួនមិនអាចប្រើបាន នៅពេលនោះ យើងបានធ្វើវាដើម្បីឱ្យចរាចរទៅកាន់ម៉ាស៊ីនមេបម្រុងទុកមួយ។ តាមទស្សនៈនៃការកំណត់រចនាសម្ព័ន្ធ ពិតណាស់មានចំណុចមួយចំនួន ប៉ុន្តែជាទូទៅអ្វីគ្រប់យ៉ាងគឺសាមញ្ញណាស់៖ យើងចុះឈ្មោះកាត ការឆ្លើយឆ្លងនៃលេខជាក់លាក់មួយទៅកាន់ IP របស់យើងនៅលើបណ្តាញ យើងនិយាយថាយើងនឹងស្តាប់នៅលើច្រក 80 ។ និង 443 យើងនិយាយថាប្រសិនបើម៉ាស៊ីនមេមិនអាចប្រើបានទេ នោះអ្នកត្រូវផ្ញើចរាចរទៅកាន់ការបម្រុងទុក ក្នុងករណីនេះទី 35 ហើយយើងពិពណ៌នាអំពីតក្កវិជ្ជាមួយចំនួនអំពីរបៀបដែលស្ថាបត្យកម្មនេះគួរតែត្រូវបានផ្តាច់។ បញ្ហាតែមួយគត់គឺថាភាសាដែលផ្នែករឹងត្រូវបានសរសេរកម្មវិធីគឺ Tcl ។ ប្រសិនបើអ្នកណាម្នាក់ចងចាំរឿងនេះទាល់តែសោះ ... ភាសានេះគឺគ្រាន់តែសរសេរច្រើនជាងភាសាដែលងាយស្រួលសម្រាប់សរសេរកម្មវិធី៖

តើយើងទទួលបានអ្វីខ្លះ? យើងបានទទួលផ្នែករឹងដែលធានានូវភាពអាចរកបានខ្ពស់នៃហេដ្ឋារចនាសម្ព័ន្ធរបស់យើង ផ្លូវធ្វើដំណើរទាំងអស់របស់យើង ផ្តល់អត្ថប្រយោជន៍សុខភាព និងដំណើរការល្អ។ លើសពីនេះទៅទៀត វាដំណើរការជាយូរណាស់មកហើយ៖ ក្នុងរយៈពេល 10 ឆ្នាំកន្លងមកនេះ មិនមានការត្អូញត្អែរអំពីវាទេ។ នៅដើមឆ្នាំ 2018 យើងបានផ្ញើរូបថតប្រហែល 80k ក្នុងមួយវិនាទីរួចហើយ។ នេះគឺជាកន្លែងណាមួយប្រហែល 80 ជីហ្គាបៃនៃចរាចរណ៍ពីមជ្ឈមណ្ឌលទិន្នន័យរបស់យើងទាំងពីរ។

ទោះយ៉ាងណាក៏ដោយ…

នៅដើមឆ្នាំ 2018 យើងបានឃើញរូបភាពមិនស្អាតនៅលើតារាង៖ ពេលវេលាដែលវាត្រូវការដើម្បីផ្ញើរូបថតបានកើនឡើងយ៉ាងច្បាស់។ ហើយវាឈប់សមនឹងយើង។ បញ្ហាគឺថាឥរិយាបថនេះអាចមើលឃើញតែក្នុងអំឡុងពេលចរាចរណ៍កំពូល - សម្រាប់ក្រុមហ៊ុនរបស់យើងនេះគឺជាយប់ពីថ្ងៃអាទិត្យដល់ថ្ងៃច័ន្ទ។ ប៉ុន្តែនៅសល់នៃពេលវេលាប្រព័ន្ធដំណើរការដូចធម្មតាមិនមានសញ្ញានៃការបរាជ័យទេ។

ទោះយ៉ាងណាក៏ដោយ បញ្ហាត្រូវតែដោះស្រាយ។ យើង​បាន​រក​ឃើញ​ការ​ស្ទះ​ដែល​អាច​កើត​មាន ហើយ​បាន​ចាប់​ផ្តើម​លុប​បំបាត់​វា​ចោល។ ជាដំបូង ជាការពិត យើងបានពង្រីកបណ្តាញភ្ជាប់ខាងក្រៅ ធ្វើសវនកម្មពេញលេញនៃតំណភ្ជាប់ខាងក្នុង និងបានរកឃើញការរាំងស្ទះដែលអាចកើតមានទាំងអស់។ ប៉ុន្តែទាំងអស់នេះមិនបានផ្តល់លទ្ធផលជាក់ស្តែងទេបញ្ហាមិនរលាយបាត់ទេ។

ការជាប់គាំងដែលអាចកើតមានមួយទៀតគឺការដំណើរការនៃឃ្លាំងសម្ងាត់រូបថតខ្លួនឯង។ ហើយ​យើង​បាន​សម្រេច​ចិត្ត​ថា​ប្រហែល​ជា​បញ្ហា​ស្ថិត​នៅ​ជាមួយ​ពួកគេ។ ជាការប្រសើរណាស់, យើងបានពង្រីកការអនុវត្ត - ជាចម្បងច្រកបណ្តាញនៅលើឃ្លាំងសម្ងាត់រូបថត។ ប៉ុន្តែ​ជា​ថ្មី​ម្តង​ទៀត​មិន​មាន​ការ​រីក​ចម្រើន​ជាក់​ស្តែង​ត្រូវ​បាន​គេ​មើល​ឃើញ​ទេ។ នៅទីបញ្ចប់ យើងបានយកចិត្តទុកដាក់លើដំណើរការរបស់ LTM ខ្លួនឯង ហើយនៅទីនេះយើងបានឃើញរូបភាពដ៏ក្រៀមក្រំនៅលើក្រាហ្វ៖ ការផ្ទុកនៅលើស៊ីភីយូទាំងអស់ចាប់ផ្តើមដំណើរការយ៉ាងរលូន ប៉ុន្តែភ្លាមៗនោះក៏មកដល់ខ្ពង់រាប។ ក្នុងពេលជាមួយគ្នានោះ LTM ឈប់ឆ្លើយតបឱ្យបានគ្រប់គ្រាន់ចំពោះការពិនិត្យសុខភាព និងការភ្ជាប់បណ្តាញភ្ជាប់ ហើយចាប់ផ្តើមបិទពួកវាដោយចៃដន្យ ដែលនាំឱ្យខូចមុខងារធ្ងន់ធ្ងរ។

នោះ​គឺ​យើង​បាន​កំណត់​ប្រភព​នៃ​បញ្ហា​បាន​កំណត់​បញ្ហា​ស្ទះ​។ វានៅសល់ដើម្បីសម្រេចថាតើយើងនឹងធ្វើអ្វី។

រឿងដំបូងដែលច្បាស់បំផុតដែលយើងអាចធ្វើបានគឺធ្វើទំនើបកម្ម LTM ខ្លួនឯង។ ប៉ុន្តែមានភាពខុសប្លែកខ្លះនៅទីនេះ ដោយសារផ្នែករឹងនេះមានលក្ខណៈប្លែកពីគេ អ្នកនឹងមិនទៅផ្សារទំនើបដែលនៅជិតបំផុត ហើយទិញវានោះទេ។ នេះគឺជាកិច្ចសន្យាដាច់ដោយឡែក កិច្ចសន្យាអាជ្ញាប័ណ្ណដាច់ដោយឡែក ហើយវានឹងចំណាយពេលច្រើន។ ជម្រើសទីពីរគឺត្រូវចាប់ផ្តើមគិតដោយខ្លួនឯង មករកដំណោះស្រាយដោយខ្លួនឯងដោយប្រើសមាសធាតុផ្ទាល់ខ្លួនរបស់អ្នក និយមប្រើកម្មវិធីបើកចំហ។ អ្វីដែលនៅសេសសល់គឺត្រូវសម្រេចចិត្តថាតើយើងនឹងជ្រើសរើសអ្វីពិតប្រាកដសម្រាប់បញ្ហានេះ និងថាតើយើងនឹងចំណាយពេលប៉ុន្មានក្នុងការដោះស្រាយបញ្ហានេះ ពីព្រោះអ្នកប្រើប្រាស់មិនបានទទួលរូបថតគ្រប់គ្រាន់។ ដូច្នេះហើយ យើងត្រូវធ្វើអ្វីៗទាំងអស់នេះឲ្យបានលឿន ដែលអាចនិយាយបានកាលពីម្សិលមិញ។

ដោយសារកិច្ចការនោះស្តាប់ទៅដូចជា "ធ្វើអ្វីមួយឱ្យលឿនតាមដែលអាចធ្វើបាន និងប្រើផ្នែករឹងដែលយើងមាន" រឿងដំបូងដែលយើងគិតគឺគ្រាន់តែដកម៉ាស៊ីនដែលមិនសូវខ្លាំងចេញពីផ្នែកខាងមុខ ដាក់ Nginx នៅទីនោះ ដែលយើងដឹងពីរបៀប ធ្វើការ ហើយព្យាយាមអនុវត្តតក្កវិជ្ជាដូចគ្នាទាំងអស់ដែលផ្នែករឹងធ្លាប់ធ្វើ។ នោះជាការពិត យើងបានចាកចេញពីផ្នែករឹងរបស់យើង ដំឡើងម៉ាស៊ីនមេ 4 បន្ថែមទៀតដែលយើងត្រូវកំណត់រចនាសម្ព័ន្ធ បង្កើតដែនខាងក្រៅសម្រាប់ពួកវា ស្រដៀងនឹងរបៀបដែលវាកាលពី 10 ឆ្នាំមុន... យើងបានបាត់បង់ភាពអាចរកបានបន្តិច ប្រសិនបើម៉ាស៊ីនទាំងនេះធ្លាក់ចុះ ប៉ុន្តែ នៅតែតិចជាងនេះ ពួកគេបានដោះស្រាយបញ្ហាអ្នកប្រើប្រាស់របស់យើងនៅក្នុងមូលដ្ឋាន។

ដូច្នោះហើយ តក្កវិជ្ជានៅតែដដែល៖ យើងដំឡើង Nginx វាអាចធ្វើ SSL-offload យើងអាចរៀបចំកម្មវិធី routing logic ពិនិត្យសុខភាពក្នុង configs ហើយគ្រាន់តែចម្លងតក្កវិជ្ជាដែលយើងមានពីមុនមក។

តោះអង្គុយសរសេរការកំណត់។ ដំបូងវាហាក់ដូចជាអ្វីៗទាំងអស់គឺសាមញ្ញណាស់ ប៉ុន្តែជាអកុសល វាពិតជាលំបាកណាស់ក្នុងការស្វែងរកសៀវភៅណែនាំសម្រាប់កិច្ចការនីមួយៗ។ ដូច្នេះហើយ យើងមិនណែនាំឲ្យគ្រាន់តែចូលទៅហ្គូហ្គល "របៀបកំណត់រចនាសម្ព័ន្ធ Nginx សម្រាប់រូបថត" ទេ៖ វាជាការប្រសើរក្នុងការយោងទៅឯកសារផ្លូវការ ដែលនឹងបង្ហាញការកំណត់ណាមួយដែលគួរត្រូវបានប៉ះ។ ប៉ុន្តែវាជាការប្រសើរក្នុងការជ្រើសរើសប៉ារ៉ាម៉ែត្រជាក់លាក់ដោយខ្លួនឯង។ មែនហើយ អ្វីៗគឺសាមញ្ញ៖ យើងពណ៌នាអំពីម៉ាស៊ីនមេដែលយើងមាន យើងពណ៌នាអំពីវិញ្ញាបនបត្រ... ប៉ុន្តែអ្វីដែលគួរឱ្យចាប់អារម្មណ៍បំផុតនោះគឺ តាមពិតទៅ តក្កវិជ្ជាកំណត់ផ្លូវដោយខ្លួនឯង។

ដំបូងវាហាក់ដូចជាពួកយើងថាយើងគ្រាន់តែពណ៌នាអំពីទីតាំងរបស់យើង ដោយផ្គូផ្គងលេខនៃឃ្លាំងសម្ងាត់រូបថតរបស់យើងនៅក្នុងនោះ ដោយប្រើដៃរបស់យើង ឬម៉ាស៊ីនភ្លើងដើម្បីពិពណ៌នាអំពីចំនួនចរន្តដែលយើងត្រូវការ ក្នុងមួយខ្សែទឹកនីមួយៗ យើងបង្ហាញម៉ាស៊ីនមេដែលចរាចរណ៍គួរ ទៅ និងម៉ាស៊ីនមេបម្រុងទុក - ប្រសិនបើម៉ាស៊ីនមេមិនអាចប្រើបាន៖

ប៉ុន្តែ ប្រហែល​ជា​ប្រសិន​បើ​អ្វីៗ​សាមញ្ញ​ពេក យើង​នឹង​ទៅ​ផ្ទះ​ដោយ​មិន​និយាយ​អ្វី​ទាំងអស់។ ជាអកុសល ជាមួយនឹងការកំណត់ Nginx លំនាំដើម ដែលជាទូទៅត្រូវបានបង្កើតឡើងក្នុងរយៈពេលជាច្រើនឆ្នាំនៃការអភិវឌ្ឍន៍ ហើយមិនសមស្របទាំងស្រុងសម្រាប់ករណីនេះទេ... ការកំណត់មើលទៅដូចនេះ៖ ប្រសិនបើម៉ាស៊ីនមេចរន្តខ្លះមានកំហុសស្នើសុំ ឬអស់ពេល Nginx តែងតែ ប្តូរចរាចរណ៍ទៅផ្លូវបន្ទាប់។ លើសពីនេះទៅទៀត បន្ទាប់ពីការបរាជ័យលើកទីមួយ ក្នុងរយៈពេល 10 វិនាទី ម៉ាស៊ីនមេក៏នឹងត្រូវបានបិទផងដែរ ទាំងកំហុស និងការអស់ពេល - វាមិនអាចកំណត់បានតាមមធ្យោបាយណាមួយឡើយ។ នោះគឺប្រសិនបើយើងដកចេញ ឬកំណត់ជម្រើសនៃការអស់ពេលឡើងវិញនៅក្នុងការណែនាំខាងលើ នោះទោះបីជា Nginx នឹងមិនដំណើរការសំណើនេះ ហើយនឹងឆ្លើយតបជាមួយនឹងកំហុសមិនល្អមួយចំនួនក៏ដោយ ក៏ម៉ាស៊ីនមេនឹងបិទ។

ដើម្បីជៀសវាងបញ្ហានេះ យើងបានធ្វើរឿងពីរយ៉ាង៖

ក) ពួកគេបានហាមឃាត់ Nginx ពីការធ្វើវាដោយដៃ - ហើយជាអកុសល មធ្យោបាយតែមួយគត់ដើម្បីធ្វើវាគឺគ្រាន់តែកំណត់ការកំណត់អតិបរមាដែលបរាជ័យ។

ខ) យើងចងចាំថានៅក្នុងគម្រោងផ្សេងទៀត យើងប្រើម៉ូឌុលដែលអនុញ្ញាតឱ្យយើងធ្វើការត្រួតពិនិត្យសុខភាពផ្ទៃខាងក្រោយ - អាស្រ័យហេតុនេះ យើងបានពិនិត្យសុខភាពញឹកញាប់ណាស់ ដូច្នេះពេលវេលារងចាំក្នុងករណីមានឧបទ្ទវហេតុនឹងមានតិចតួចបំផុត។

ជាអកុសល នេះមិនមែនទាំងអស់នោះទេ ពីព្រោះតាមព្យញ្ជនៈ ពីរសប្តាហ៍ដំបូងនៃប្រតិបត្តិការនៃគ្រោងការណ៍នេះបានបង្ហាញថា ការត្រួតពិនិត្យសុខភាព TCP ក៏ជារឿងមិនគួរទុកចិត្តផងដែរ៖ នៅលើម៉ាស៊ីនមេខាងលើ វាអាចមិនមែនជា Nginx ឬ Nginx នៅក្នុងរដ្ឋ D និងនៅក្នុង ករណីនេះ ខឺណែលនឹងទទួលយកការតភ្ជាប់ ការពិនិត្យសុខភាពនឹងហុច ប៉ុន្តែនឹងមិនដំណើរការទេ។ ដូច្នេះហើយ យើងបានជំនួសវាភ្លាមៗជាមួយនឹងការពិនិត្យសុខភាព http បង្កើតជាក់លាក់មួយ ដែលប្រសិនបើវាត្រលប់មកវិញ 200 នោះអ្វីៗដំណើរការនៅក្នុងស្គ្រីបនេះ។ អ្នកអាចធ្វើតក្កវិជ្ជាបន្ថែម - ឧទាហរណ៍ក្នុងករណីម៉ាស៊ីនមេឃ្លាំងសម្ងាត់ សូមពិនិត្យមើលថាប្រព័ន្ធឯកសារត្រូវបានម៉ោនត្រឹមត្រូវ៖

ហើយវានឹងសាកសមនឹងយើង លើកលែងតែនៅពេលនោះ សៀគ្វីបានធ្វើម្តងទៀតនូវអ្វីដែលផ្នែករឹងបានធ្វើ។ ប៉ុន្តែយើងចង់ធ្វើបានល្អជាងនេះ។ ពីមុនយើងមានម៉ាស៊ីនមេបម្រុងទុកមួយ ហើយនេះប្រហែលជាមិនល្អទេ ព្រោះប្រសិនបើអ្នកមានម៉ាស៊ីនមេមួយរយ នោះនៅពេលដែលបរាជ័យជាច្រើនក្នុងពេលតែមួយ នោះម៉ាស៊ីនមេបម្រុងទុកមួយទំនងជាមិនអាចទប់ទល់នឹងបន្ទុកបានទេ។ ដូច្នេះហើយ យើងបានសម្រេចចិត្តចែកចាយការកក់ទុកនៅទូទាំង servers ទាំងអស់៖ យើងគ្រាន់តែបង្កើតចរន្តដាច់ដោយឡែកមួយទៀត សរសេរ servers ទាំងអស់នៅទីនោះជាមួយនឹងប៉ារ៉ាម៉ែត្រជាក់លាក់ស្របតាមបន្ទុកដែលពួកគេអាចបម្រើបាន បន្ថែមការត្រួតពិនិត្យសុខភាពដូចគ្នាដែលយើងមានពីមុនមក៖

ដោយសារវាមិនអាចទៅរួចទេក្នុងការចូលទៅកាន់ប្រភពទឹកមួយទៀតនៅក្នុងចរន្តទឹកមួយ វាចាំបាច់ក្នុងការធ្វើឱ្យប្រាកដថាប្រសិនបើប្រភពទឹកសំខាន់ដែលយើងគ្រាន់តែកត់ត្រាឃ្លាំងសម្ងាត់រូបថតដែលត្រឹមត្រូវ និងចាំបាច់នោះមិនអាចប្រើបាន នោះយើងគ្រាន់តែឆ្លងកាត់ error_page ទៅកាន់ fallback ពី កន្លែងដែលយើងបានទៅការបម្រុងទុកខាងលើ៖

ហើយដោយការបន្ថែមម៉ាស៊ីនមេចំនួនបួនតាមព្យញ្ជនៈ នេះជាអ្វីដែលយើងទទួលបាន៖ យើងបានជំនួសផ្នែកនៃបន្ទុក - យើងបានដកវាចេញពី LTM ទៅម៉ាស៊ីនមេទាំងនេះ អនុវត្តតក្កវិជ្ជាដូចគ្នានៅទីនោះ ដោយប្រើផ្នែករឹង និងសូហ្វវែរស្តង់ដារ ហើយទទួលបានប្រាក់រង្វាន់ភ្លាមៗដែលម៉ាស៊ីនមេទាំងនេះអាច ធ្វើមាត្រដ្ឋាន ព្រោះពួកគេអាចផ្គត់ផ្គង់បានច្រើនតាមតម្រូវការ។ ជាការប្រសើរណាស់, អវិជ្ជមានតែមួយគត់គឺថាយើងបានបាត់បង់លទ្ធភាពខ្ពស់សម្រាប់អ្នកប្រើប្រាស់ខាងក្រៅ។ ប៉ុន្តែ​នៅ​ពេល​នោះ យើង​ត្រូវ​លះបង់​រឿង​នេះ ព្រោះ​ត្រូវ​ដោះស្រាយ​ភ្លាម។ ដូច្នេះ យើងបានដកផ្នែកមួយនៃបន្ទុកចេញ វាគឺប្រហែល 40% នៅពេលនោះ LTM មានអារម្មណ៍ល្អ ហើយតាមព្យញ្ជនៈពីរសប្តាហ៍បន្ទាប់ពីបញ្ហាបានចាប់ផ្តើម យើងបានចាប់ផ្តើមផ្ញើសំណើមិនមែន 45k ក្នុងមួយវិនាទី ប៉ុន្តែ 55k ។ តាមពិតយើងបានកើនឡើង 20% - នេះច្បាស់ណាស់ចរាចរដែលយើងមិនបានផ្តល់ឱ្យអ្នកប្រើប្រាស់។ ហើយបន្ទាប់ពីនោះពួកគេបានចាប់ផ្តើមគិតអំពីរបៀបដោះស្រាយបញ្ហាដែលនៅសេសសល់ - ដើម្បីធានាបាននូវលទ្ធភាពប្រើប្រាស់ខាងក្រៅខ្ពស់។

យើង​បាន​ផ្អាក​ខ្លះ​ក្នុង​អំឡុង​ពេល​ដែល​យើង​ពិភាក្សា​អំពី​ដំណោះស្រាយ​អ្វី​ដែល​យើង​នឹង​ប្រើ​សម្រាប់​បញ្ហា​នេះ។ មានសំណើដើម្បីធានាបាននូវភាពជឿជាក់ដោយប្រើ DNS ដោយមានជំនួយពីស្គ្រីបដែលសរសេរតាមផ្ទះ ពិធីការបញ្ជូនផ្លូវថាមវន្ត... មានជម្រើសជាច្រើន ប៉ុន្តែវាបានច្បាស់រួចហើយថាសម្រាប់ការចែកចាយរូបថតដែលគួរឱ្យទុកចិត្តបានពិតប្រាកដ អ្នកត្រូវណែនាំស្រទាប់មួយផ្សេងទៀតដែល នឹងតាមដានរឿងនេះ។ យើង​បាន​ហៅ​ម៉ាស៊ីន​ថត​រូប​ទាំង​នេះ​ថា​ជា​នាយក​រូបថត។ កម្មវិធីដែលយើងពឹងផ្អែកលើគឺ Keepalived៖

ដើម្បីចាប់ផ្តើមជាមួយតើ Keepalived មានអ្វីខ្លះ? ទីមួយគឺពិធីការ VRRP ដែលត្រូវបានគេស្គាល់យ៉ាងទូលំទូលាយចំពោះអ្នកបណ្តាញ ដែលមានទីតាំងនៅលើឧបករណ៍បណ្តាញដែលផ្តល់នូវការអត់ឱនចំពោះកំហុសចំពោះអាសយដ្ឋាន IP ខាងក្រៅដែលអតិថិជនភ្ជាប់។ ផ្នែកទីពីរគឺ IPVS ដែលជាម៉ាស៊ីនមេនិម្មិត IP សម្រាប់តុល្យភាពរវាងរ៉ោតទ័ររូបថត និងធានាការអត់ឱនចំពោះកំហុសនៅកម្រិតនេះ។ និងទីបី - ការពិនិត្យសុខភាព។

តោះចាប់ផ្តើមជាមួយផ្នែកទីមួយ៖ VRRP - តើវាមើលទៅដូចអ្វី? មាន IP និម្មិតជាក់លាក់មួយដែលមានធាតុនៅក្នុង dns badoocdn.com ដែលអតិថិជនភ្ជាប់។ នៅពេលណាមួយ យើងមានអាសយដ្ឋាន IP នៅលើម៉ាស៊ីនមេមួយ។ កញ្ចប់ Keepalived ដំណើរការរវាងម៉ាស៊ីនមេដោយប្រើពិធីការ VRRP ហើយប្រសិនបើមេបាត់ពីរ៉ាដា - ម៉ាស៊ីនមេបានចាប់ផ្ដើមឡើងវិញ ឬអ្វីផ្សេងទៀតនោះ ម៉ាស៊ីនមេបម្រុងទុកនឹងយកអាសយដ្ឋាន IP នេះដោយស្វ័យប្រវត្តិ - មិនចាំបាច់មានសកម្មភាពដោយដៃទេ។ ភាពខុសគ្នារវាងមេ និងការបម្រុងទុកគឺជាអាទិភាពចម្បង៖ វាកាន់តែខ្ពស់ ឱកាសកាន់តែច្រើនដែលម៉ាស៊ីននឹងក្លាយជាមេ។ អត្ថប្រយោជន៍ដ៏ធំមួយគឺថាអ្នកមិនចាំបាច់កំណត់រចនាសម្ព័ន្ធអាសយដ្ឋាន IP នៅលើម៉ាស៊ីនមេដោយខ្លួនឯង វាគ្រប់គ្រាន់ដើម្បីពិពណ៌នាពួកវានៅក្នុងការកំណត់ ហើយប្រសិនបើអាសយដ្ឋាន IP ត្រូវការច្បាប់កំណត់ផ្លូវផ្ទាល់ខ្លួនមួយចំនួន វាត្រូវបានពិពណ៌នាដោយផ្ទាល់នៅក្នុងការកំណត់ដោយប្រើ វាក្យសម្ព័ន្ធដូចគ្នាដូចដែលបានពិពណ៌នានៅក្នុងកញ្ចប់ VRRP ។ អ្នកនឹងមិនជួបរឿងដែលមិនធ្លាប់ស្គាល់ទេ។

តើនេះមើលទៅដូចអ្វីនៅក្នុងការអនុវត្ត? តើមានអ្វីកើតឡើងប្រសិនបើម៉ាស៊ីនមេណាមួយបរាជ័យ? នៅពេលដែលមេបាត់ ការបម្រុងទុករបស់យើងឈប់ទទួលការផ្សាយពាណិជ្ជកម្ម ហើយក្លាយជាម្ចាស់ដោយស្វ័យប្រវត្តិ។ បន្ទាប់ពីពេលខ្លះ យើងបានជួសជុលមេ ចាប់ផ្ដើមឡើងវិញ លើក Keepalived - ការផ្សាយពាណិជ្ជកម្មមកដល់មានអាទិភាពខ្ពស់ជាងការបម្រុងទុក ហើយការបម្រុងទុកនឹងត្រលប់មកវិញដោយស្វ័យប្រវត្តិ ដកអាសយដ្ឋាន IP ចេញ មិនចាំបាច់ធ្វើដោយដៃទេ។

ដូច្នេះ យើង​បាន​ធានា​ការ​អត់ឱន​ចំពោះ​កំហុស​នៃ​អាសយដ្ឋាន IP ខាងក្រៅ។ ផ្នែកបន្ទាប់គឺដើម្បីធ្វើឱ្យមានតុល្យភាពចរាចរពីអាសយដ្ឋាន IP ខាងក្រៅទៅកាន់រ៉ោតទ័ររូបថតដែលកំពុងបិទវារួចហើយ។ អ្វីគ្រប់យ៉ាងគឺច្បាស់ណាស់ជាមួយនឹងពិធីការតុល្យភាព។ នេះ​គឺ​ជា​ការ​ជុំ​គ្នា​សាមញ្ញ​ឬ​អ្វី​ដែល​ស្មុគស្មាញ​ជាង​នេះ​បន្តិច, wrr, ការ​តភ្ជាប់​បញ្ជី​និង​ដូច្នេះ​នៅ​លើ​។ នេះត្រូវបានពិពណ៌នាជាមូលដ្ឋាននៅក្នុងឯកសារ មិនមានអ្វីពិសេសនោះទេ។ ប៉ុន្តែវិធីសាស្រ្តចែកចាយ... ខាងក្រោមនេះយើងនឹងពិនិត្យមើលឱ្យកាន់តែច្បាស់អំពីមូលហេតុដែលយើងជ្រើសរើសមួយក្នុងចំណោមពួកគេ។ ទាំងនេះគឺជា NAT, Direct Routing និង TUN ។ ការពិតគឺថា ភ្លាមៗនោះ ពួកយើងគ្រោងនឹងបញ្ជូន 100 gigabits នៃចរាចរណ៍ពីគេហទំព័រ។ ប្រសិនបើអ្នកប៉ាន់ស្មាន អ្នកត្រូវការកាត 10 ជីហ្គាប៊ីតមែនទេ? កាត 10 ជីហ្គាប៊ីតនៅក្នុងម៉ាស៊ីនមេមួយគឺហួសពីវិសាលភាពនៃគំនិត "ឧបករណ៍ស្តង់ដារ" របស់យើងរួចទៅហើយ។ ហើយ​បន្ទាប់​មក យើង​នឹក​ឃើញ​ថា យើង​មិន​គ្រាន់​តែ​ចែក​ផ្លូវ​មួយ​ចំនួន​ទេ គឺ​យើង​ផ្ដល់​រូបថត។

តើមានអ្វីពិសេស? - ភាពខុសគ្នាខ្លាំងរវាងចរាចរណ៍ចូល និងចេញ។ ចរាចរណ៍ចូលគឺតូចណាស់ ចរាចរណ៍ចេញមានទំហំធំណាស់៖

ប្រសិនបើអ្នកក្រឡេកមើលក្រាហ្វទាំងនេះ អ្នកអាចមើលឃើញថានៅពេលនេះនាយកកំពុងទទួលបានប្រហែល 200 MB ក្នុងមួយវិនាទី នេះគឺជាថ្ងៃធម្មតាណាស់។ យើងផ្តល់ឱ្យត្រឡប់មកវិញ 4,500 MB ក្នុងមួយវិនាទី សមាមាត្ររបស់យើងគឺប្រហែល 1/22 ។ វាច្បាស់ហើយថា ដើម្បីផ្តល់ចរាចរចេញពេញលេញដល់ម៉ាស៊ីនមេកម្មករ 22 នាក់ យើងត្រូវការតែមួយគត់ដែលទទួលយកការតភ្ជាប់នេះ។ នេះគឺជាកន្លែងដែលក្បួនដោះស្រាយការនាំផ្លូវដោយផ្ទាល់មករកជំនួយរបស់យើង។

តើវាមើលទៅដូចអ្វី? នាយករូបថតរបស់យើងយោងទៅតាមតារាងរបស់គាត់បញ្ជូនការតភ្ជាប់ទៅរ៉ោតទ័ររូបថត។ ប៉ុន្តែរ៉ោតទ័ររូបថតបញ្ជូនចរាចរដោយផ្ទាល់ទៅអ៊ីនធឺណិតផ្ញើវាទៅម៉ាស៊ីនភ្ញៀវវាមិនត្រលប់មកវិញតាមរយៈនាយករូបថតទេដូច្នេះជាមួយនឹងចំនួនអប្បបរមានៃម៉ាស៊ីនយើងធានានូវការអត់ធ្មត់ពេញលេញនិងការបូមចរាចរទាំងអស់។ នៅក្នុងការកំណត់រចនាសម្ព័ន្ធវាមើលទៅដូចនេះ៖ យើងបញ្ជាក់ក្បួនដោះស្រាយ ក្នុងករណីរបស់យើងវាជា rr សាមញ្ញ ផ្តល់វិធីសាស្ត្រកំណត់ផ្លូវដោយផ្ទាល់ ហើយបន្ទាប់មកចាប់ផ្តើមរាយបញ្ជីម៉ាស៊ីនមេពិតប្រាកដទាំងអស់ តើយើងមានចំនួនប៉ុន្មាន។ ដែលនឹងកំណត់ចរាចរណ៍នេះ។ ប្រសិនបើយើងមានម៉ាស៊ីនមេមួយ ឬពីរបន្ថែមទៀតនៅទីនោះ ឬម៉ាស៊ីនមេជាច្រើន តម្រូវការបែបនេះកើតឡើង - យើងគ្រាន់តែបន្ថែមផ្នែកនេះទៅក្នុងការកំណត់ ហើយកុំបារម្ភច្រើនពេក។ ពីផ្នែកម្ខាងនៃម៉ាស៊ីនមេពិតប្រាកដ ពីផ្នែកម្ខាងនៃរ៉ោតទ័ររូបថត វិធីសាស្ត្រនេះតម្រូវឱ្យមានការកំណត់រចនាសម្ព័ន្ធតិចតួចបំផុត វាត្រូវបានពិពណ៌នាយ៉ាងល្អឥតខ្ចោះនៅក្នុងឯកសារ ហើយគ្មានបញ្ហានៅទីនោះទេ។

អ្វី​ដែល​ល្អ​ពិសេស​នោះ​គឺ​ដំណោះស្រាយ​បែប​នេះ​មិន​មាន​ន័យ​ថា​ជា​ការ​រចនា​បណ្តាញ​ក្នុង​ស្រុក​ឡើង​វិញ​ទេ វា​សំខាន់​សម្រាប់​យើង យើង​ត្រូវ​ដោះស្រាយ​វា​ដោយ​ចំណាយ​តិច​បំផុត។ ប្រសិនបើអ្នកក្រឡេកមើល លទ្ធផលពាក្យបញ្ជាគ្រប់គ្រង IPVSបន្ទាប់មកយើងនឹងឃើញថាតើវាមើលទៅដូចអ្វី។ នៅទីនេះយើងមានម៉ាស៊ីនមេនិម្មិតជាក់លាក់មួយនៅលើច្រក 443 ស្តាប់ ទទួលយកការតភ្ជាប់ រាល់ម៉ាស៊ីនមេដែលកំពុងដំណើរការត្រូវបានរាយបញ្ជី ហើយអ្នកអាចមើលឃើញថាការតភ្ជាប់គឺ ផ្តល់ឱ្យ ឬយកដូចគ្នា។ ប្រសិនបើយើងក្រឡេកមើលស្ថិតិនៅលើម៉ាស៊ីនមេនិម្មិតដូចគ្នា យើងមានកញ្ចប់ព័ត៌មានចូល ការតភ្ជាប់ចូល ប៉ុន្តែពិតជាគ្មានច្រកចេញទេ។ ការតភ្ជាប់ចេញទៅកាន់អតិថិជនដោយផ្ទាល់។ មិនអីទេ យើងអាចដកវាចេញបាន។ ឥឡូវនេះ តើមានអ្វីកើតឡើង ប្រសិនបើរ៉ោតទ័ររូបថតមួយរបស់យើងបរាជ័យ? យ៉ាងណាមិញជាតិដែកគឺជាជាតិដែក។ វាអាចចូលទៅក្នុងការភ័យស្លន់ស្លោ ខឺណែល វាអាចនឹងខូច ការផ្គត់ផ្គង់ថាមពលអាចនឹងឆេះ។ អ្វីក៏បាន។ នេះ​ជា​មូលហេតុ​ចាំបាច់​ត្រូវ​ពិនិត្យ​សុខភាព។ ពួកវាអាចមានលក្ខណៈសាមញ្ញដូចជាការពិនិត្យមើលរបៀបដែលច្រកបើក ឬអ្វីដែលស្មុគស្មាញជាងនេះ រហូតដល់ស្គ្រីបដែលសរសេរតាមផ្ទះមួយចំនួនដែលនឹងពិនិត្យមើលតក្កវិជ្ជាអាជីវកម្ម។

យើងបានឈប់នៅកន្លែងណាមួយនៅកណ្តាល៖ យើងមានសំណើ https ទៅកាន់ទីតាំងជាក់លាក់មួយ ស្គ្រីបត្រូវបានហៅ ប្រសិនបើវាឆ្លើយតបជាមួយនឹងការឆ្លើយតប 200 យើងជឿថាអ្វីគ្រប់យ៉ាងគឺល្អជាមួយម៉ាស៊ីនមេនេះ វានៅរស់ ហើយអាចបើកបាន យ៉ាង​ងាយស្រួល។

តើនេះមើលទៅក្នុងការអនុវត្តវិញដោយរបៀបណា? តោះបិទម៉ាស៊ីនមេសម្រាប់ការថែទាំ - បញ្ចេញ BIOS ជាឧទាហរណ៍។ នៅក្នុងកំណត់ហេតុ យើងមានការអស់ពេលភ្លាមៗ យើងឃើញបន្ទាត់ទីមួយ បន្ទាប់មកបន្ទាប់ពីការព្យាយាមបីដង វាត្រូវបានសម្គាល់ថា "បរាជ័យ" ហើយវាត្រូវបានដកចេញយ៉ាងសាមញ្ញពីបញ្ជី។

ជម្រើសឥរិយាបថទីពីរក៏អាចធ្វើទៅបានដែរ នៅពេលដែល VS ត្រូវបានកំណត់ត្រឹមសូន្យ ប៉ុន្តែប្រសិនបើរូបថតត្រូវបានត្រឡប់មកវិញ វាមិនដំណើរការល្អទេ។ ម៉ាស៊ីនមេកើតឡើង Nginx ចាប់ផ្តើមនៅទីនោះ ការពិនិត្យសុខភាព យល់ភ្លាមៗថាការតភ្ជាប់កំពុងដំណើរការ អ្វីគ្រប់យ៉ាងគឺល្អ ហើយម៉ាស៊ីនមេលេចឡើងក្នុងបញ្ជីរបស់យើង ហើយការផ្ទុកភ្លាមៗចាប់ផ្តើមអនុវត្តចំពោះវា។ មិនតម្រូវឱ្យមានសកម្មភាពដោយដៃពីអ្នកគ្រប់គ្រងកាតព្វកិច្ចទេ។ ម៉ាស៊ីនមេបានដំណើរការឡើងវិញនៅពេលយប់ - នាយកដ្ឋានត្រួតពិនិត្យមិនទូរស័ព្ទមកយើងអំពីរឿងនេះនៅពេលយប់ទេ។ ពួកគេប្រាប់អ្នកថារឿងនេះបានកើតឡើង អ្វីគ្រប់យ៉ាងគឺល្អ។

ដូច្នេះ តាមវិធីសាមញ្ញមួយ ដោយមានជំនួយពីម៉ាស៊ីនមេមួយចំនួនតូច យើងបានដោះស្រាយបញ្ហានៃការអត់ឱនចំពោះកំហុសខាងក្រៅ។

អ្វី​ដែល​នៅ​តែ​និយាយ​គឺ​ថា​អ្វី​ទាំង​អស់​នេះ​ជា​ការ​ពិត​ណាស់​ត្រូវ​ការ​ត្រួត​ពិនិត្យ​។ ដោយឡែកពីគ្នា វាគួរតែត្រូវបានកត់សម្គាល់ថា Keepalivede ជាកម្មវិធីដែលបានសរសេរតាំងពីយូរយារណាស់មកហើយ មានវិធីជាច្រើនក្នុងការត្រួតពិនិត្យវា ទាំងការប្រើការត្រួតពិនិត្យតាមរយៈ DBus, SMTP, SNMP និងស្តង់ដារ Zabbix ។ លើសពីនេះ គាត់ខ្លួនឯងចេះសរសេរអក្សរស្ទើរតែគ្រប់ការកណ្តាស់ ហើយនិយាយឱ្យត្រង់ទៅ ពេលខ្លះយើងថែមទាំងគិតចង់បិទវាទៀតផង ព្រោះគាត់សរសេរអក្សរច្រើនណាស់សម្រាប់រាល់ចរាចរណ៍ បិទបើក រាល់ការភ្ជាប់ IP។ ហើយដូច្នេះនៅលើ។ ជាការពិតណាស់ ប្រសិនបើមានម៉ាស៊ីនមេច្រើន នោះអ្នកអាចយកឈ្នះលើខ្លួនអ្នកជាមួយនឹងអក្សរទាំងនេះ។ យើងត្រួតពិនិត្យ nginx នៅលើរ៉ោតទ័ររូបថតដោយប្រើវិធីសាស្ត្រស្តង់ដារ ហើយការត្រួតពិនិត្យផ្នែករឹងមិនបាត់ទៅណាទេ។ ជាការពិតណាស់ យើងនឹងណែនាំរឿងពីរបន្ថែមទៀត៖ ទីមួយ ការពិនិត្យសុខភាពខាងក្រៅ និងភាពអាចរកបាន ពីព្រោះទោះបីជាអ្វីៗដំណើរការក៏ដោយ តាមពិតប្រហែលជាអ្នកប្រើប្រាស់មិនទទួលបានរូបថតដោយសារតែបញ្ហាជាមួយអ្នកផ្តល់សេវាខាងក្រៅ ឬអ្វីមួយដែលស្មុគស្មាញជាងនេះ។ វាតែងតែមានតម្លៃរក្សាកន្លែងណាមួយនៅលើបណ្តាញផ្សេងទៀត នៅក្នុង Amazon ឬកន្លែងផ្សេងទៀត ដែលជាម៉ាស៊ីនដាច់ដោយឡែកដែលអាច ping servers របស់អ្នកពីខាងក្រៅ ហើយវាក៏មានតម្លៃផងដែរក្នុងការប្រើការរកឃើញភាពមិនប្រក្រតី សម្រាប់អ្នកដែលដឹងពីរបៀបធ្វើ ការរៀនម៉ាស៊ីនដែលមានល្បិច ឬការត្រួតពិនិត្យសាមញ្ញ។ យ៉ាងហោចណាស់ដើម្បីតាមដានថាតើសំណើបានធ្លាក់ចុះយ៉ាងខ្លាំង ឬផ្ទុយទៅវិញបានកើនឡើង។ វាក៏អាចមានប្រយោជន៍ផងដែរ។

សរុបមក៖ តាមពិតទៅ យើងបានជំនួសដំណោះ ស្រាយដែលធ្វើពីដែក ដែលនៅចំណុចខ្លះបានឈប់សាកសមនឹងយើង ជាមួយនឹងប្រព័ន្ធដ៏សាមញ្ញមួយ ដែលធ្វើអ្វីគ្រប់យ៉ាងដូចគ្នា ពោលគឺវាផ្តល់នូវការបញ្ចប់ចរាចរណ៍ HTTPS និងការកំណត់ផ្លូវឆ្លាតវៃបន្ថែមទៀតជាមួយនឹង ការពិនិត្យសុខភាពចាំបាច់។ យើងបានបង្កើនស្ថេរភាពនៃប្រព័ន្ធនេះ ពោលគឺយើងនៅតែមានភាពអាចរកបានខ្ពស់សម្រាប់ស្រទាប់នីមួយៗ បូករួមទាំងប្រាក់រង្វាន់ដែលវាងាយស្រួលក្នុងការធ្វើមាត្រដ្ឋានវាទាំងអស់នៅលើស្រទាប់នីមួយៗ ព្រោះវាជាផ្នែករឹងស្តង់ដារជាមួយនឹងកម្មវិធីស្តង់ដារ នោះគឺ យើងបានសម្រួលការវិនិច្ឆ័យបញ្ហាដែលអាចកើតមាន។

តើយើងបញ្ចប់ដោយអ្វី? យើងមានបញ្ហាក្នុងអំឡុងពេលថ្ងៃឈប់សម្រាកខែមករាឆ្នាំ 2018 ។ ក្នុងរយៈពេលប្រាំមួយខែដំបូង ខណៈពេលដែលយើងដាក់គម្រោងនេះឱ្យដំណើរការ យើងបានពង្រីកវាទៅគ្រប់ចរាចរណ៍ ដើម្បីដកចរាចរទាំងអស់ចេញពី LTM យើងបានកើនឡើងតែនៅក្នុងចរាចរណ៍នៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យមួយពី 40 gigabits ទៅ 60 gigabits ហើយក្នុងពេលតែមួយសម្រាប់ ឆ្នាំ 2018 ទាំងមូលអាចផ្ញើរូបថតជិតបីដងច្រើនជាងក្នុងមួយវិនាទី។

ប្រភព: www.habr.com