วันนี้ Bitrix นำเสนอโซลูชั่นใหม่ – “เว็บคลัสเตอร์” สำหรับผู้ที่ไม่ทราบ ฉันจะอธิบายว่าสิ่งนี้ช่วยให้คุณสามารถวางโปรเจ็กต์ที่มีผู้เยี่ยมชมสูงไม่ได้บนเซิร์ฟเวอร์เดียว แต่บนเซิร์ฟเวอร์หลายเครื่อง และเพิ่มเซิร์ฟเวอร์ใหม่ได้ตลอดเวลาเพื่อเร่งความเร็วไซต์ นอกจากนี้ ยังปลอดภัยที่จะลบเซิร์ฟเวอร์ใดๆ เพื่อการซ่อมแซม อัปเกรด หรือในกรณีที่เกิดข้อผิดพลาด แน่นอนว่าในฐานะคู่แข่งรายแรกของพวกเขา (แสดงโดยบริษัท Yumisoft) ก่อนอื่นฉันต้องค้นหาว่าพื้นฐานใหม่ที่พวกเขานำเสนอสู่ตลาดคืออะไร

ไม่มีอะไร. ไม่มีอะไรในทางที่ดี Bitrix หยุดการหลอกลวงและ "คิดค้นล้อขึ้นมาใหม่" - เห็นได้ชัดว่ามีนักเทคโนโลยีที่ชาญฉลาดเข้ามาร่วมทีม ดังนั้นแทนที่จะใช้ "จักรยาน" พวกเขาจึงรับและทำทุกอย่างเหมือนที่คนปกติทั่วไปทำ ในโพสต์นี้ฉันจะบอก ด้วยคำพูดง่ายๆ– พวกเขาทำอะไรกันแน่ และคุณจะทำซ้ำสิ่งเดียวกันในโครงการของคุณได้อย่างไร

ลองดูส่วนหลักของคลัสเตอร์:

0. คลาวด์ – คลาวด์ ซึ่งเป็นชุดของเซิร์ฟเวอร์ที่ทั้งหมดนี้จะทำงาน
1. โหลดบาลานเซอร์ – โหลดบาลานเซอร์ที่เข้ามา
2. การจำลองแบบ MySQL เป็นรูปแบบคลัสเตอร์ฐานข้อมูลที่ได้รับความนิยม
3. เครือข่าย ระบบไฟล์– กระจาย การจัดเก็บไฟล์.

ตามที่กล่าวไว้ข้างต้น คลัสเตอร์คือชุดของเว็บเซิร์ฟเวอร์ตามจำนวนที่กำหนด พวกเขาสามารถทำงานเดียวกันหรืองานที่แตกต่างกันได้ขึ้นอยู่กับเป้าหมาย เริ่มจากเซิร์ฟเวอร์กันก่อน: ขอเสนอให้ใช้เครื่องเสมือน aws.amazon.com สำหรับพวกเขา ฉันจะไม่บอกว่านี่เป็นวิธีแก้ปัญหาที่สมเหตุสมผล: เครื่องเสมือนนั้นช้า แต่ที่นี่ จุดสำคัญ- ความง่ายในการสร้าง ฉันกดปุ่มและมันก็ถูกสร้างขึ้น และไม่ใช่เครื่องเริ่มต้น แต่เป็นเครื่องที่กำหนดค่าตามความต้องการของคุณโดยเฉพาะ คุณสามารถสร้างมันตามกำหนดเวลาหรือแม้แต่แบบไดนามิกเมื่อโหลดเพิ่มขึ้น ไซต์ของคุณถูกโจมตี การไหลที่ทรงพลังผู้เยี่ยมชม - มัน r-r-r-az และสร้างเครื่องจักรใหม่หลายเครื่อง การโหลดสิ้นสุดลง - เครื่องปิดอยู่ ความงาม.

แน่นอนว่าเซิร์ฟเวอร์ใดๆ บนอินเทอร์เน็ตสามารถทำหน้าที่เป็นเซิร์ฟเวอร์คลัสเตอร์ได้ ไม่ว่าจะเป็นเซิร์ฟเวอร์เสมือนหรือฮาร์ดแวร์ สำหรับการอ้างอิง: ใครก็ตามที่ไม่ขี้เกียจเกินไปที่จะเริ่มติดตั้งใหม่สามารถสร้างคลัสเตอร์ "Amazon" ส่วนตัวของตนเองได้ฟรี การกระจายอูบุนตูเซิร์ฟเวอร์

จำเป็นต้องมีบาลานเซอร์เพื่อกระจายคำขอขาเข้าจากผู้เยี่ยมชมไซต์ระหว่างเซิร์ฟเวอร์คลัสเตอร์ ขอเสนอให้ใช้ nginx แทน Google "สมดุลโหลด nginx" และคุณจะได้รับลิงก์มากมายไปยังตัวอย่างสำเร็จรูป

จำเป็นต้องมีการจำลองฐานข้อมูลเพื่อเขียนข้อมูลบนเซิร์ฟเวอร์เดียว (เรียกว่ามาสเตอร์) และอ่านจากเซิร์ฟเวอร์อื่นทั้งหมด (ตามลำดับ สเลฟ) เนื่องจากโดยปกติแล้วจะมีการดำเนินการเขียนเพียงเล็กน้อยและการดำเนินการอ่านจำนวนมาก เพียงเพิ่มจำนวนทาส คุณก็จะสามารถเพิ่ม "พลัง" ของโปรเจ็กต์ได้อย่างไม่จำกัด ข้อมูลจากมาสเตอร์ถึงทาสไหลเข้ามา พื้นหลังใช้ MySQL เพียงอย่างเดียว และสามารถเพิ่มและลบทาสได้ตลอดเวลา Google “การจำลองแบบ mysql” และรับคำแนะนำ

พื้นที่จัดเก็บไฟล์แบบกระจายเป็นสิ่งจำเป็นเพื่อให้แน่ใจว่าเซิร์ฟเวอร์ทั้งหมดมีไฟล์ชุดเดียวกัน หากผู้ใช้อัปโหลดรูปภาพ "ที่ไหนสักแห่ง" ไปยังเซิร์ฟเวอร์ตัวใดตัวหนึ่ง รูปภาพนั้นควรจะปรากฏทุกที่ ทำไม เนื่องจากข้อมูลอาจถูกมอบให้กับผู้ใช้รายอื่นจากเซิร์ฟเวอร์อื่น สำหรับการนำไปใช้สหายจาก Bitrix ขอแนะนำ "csync2" ซึ่งทำงานในพื้นหลังและซิงโครไนซ์ไฟล์ระหว่างเซิร์ฟเวอร์อย่างโง่เขลาเพื่อให้ทุกอย่างเหมือนกันทุกที่

ทั้งหมด. ดังนั้นคุณจึงได้สร้างคลัสเตอร์ และตอนนี้ – การปรับแต่งแบบละเอียด:

สิ่งกีดขวางแรกที่คุณจะสะดุดเมื่อถ่ายโอนโปรเจ็กต์ของคุณ (ฉันหมายถึงโปรเจ็กต์บน CMS อื่นหรือโปรเจ็กต์ที่เขียนเอง) ไปยังโมเดลดังกล่าวจะอยู่ในการทำงานของฐานข้อมูล สิ่งที่สำคัญที่สุดคือแอปพลิเคชันจะต้องสามารถแยกแยะคำขอ "การเขียน" จากคำขอ "การอ่าน" ได้ กล่าวอีกนัยหนึ่ง INSERT, UPDATE, DELETE รวมถึง CREATE, ALTER และ DROP จำเป็นต้องดำเนินการบนต้นแบบเท่านั้น แบบสอบถามที่เลือกโดยหลักการแล้วสามารถทำได้ทุกที่ จะต้องใช้เวลาค่อนข้างมากในการฝึกเครื่องยนต์ของคุณใหม่ให้มีความคิดเช่นนี้

นอกจากนี้ Bitrixoids ยังคิดค้น สิ่งที่น่าสนใจ: เนื่องจากข้อมูลจากต้นแบบไปยังทาสด้วยความล่าช้า พวกเขาจึงสอนระบบให้จดจำคำขอเขียนที่ "สำคัญ" หลังจากการร้องขอ ข้อมูลทั้งหมดจนถึงจุดสิ้นสุดของการเรียกใช้สคริปต์ PHP จะถูกดึง (SELECT) จากต้นแบบเท่านั้น เพื่อหลีกเลี่ยงข้อผิดพลาดเนื่องจากความล่าช้าเดียวกันนั้น

แนวคิดที่สองที่ต้องพิจารณาคือการจัดสรรเซิร์ฟเวอร์สำหรับงาน ไม่จำเป็นต้องทำให้เซิร์ฟเวอร์ทั้งหมดเหมือนกันและมอบหมายงานให้เหมือนกัน ให้บางส่วนให้บริการ เช่น ร้านค้าออนไลน์ และอีกส่วนหนึ่งเก็บสถิติ

ความคิดที่สามคือการจัดกลุ่มแบบ memcached Bitrix รวมไว้ตอนเริ่มต้นการนำเสนอ แต่คุณสามารถเปิดใช้งานได้ในภายหลัง ข้อได้เปรียบของมันคือเชื่อมต่อโดยตรงกับ nginx (จำจุดแรกได้ไหม) และอนุญาตให้ให้บริการหน้าแคช (หรือบล็อก) ได้โดยตรงจาก แรม- งานของคุณ - หรืองานสคริปต์ของคุณ - คือการวางเนื้อหาที่แคชไว้ใน memcached

จะพัฒนาโปรเจ็กต์บนคลัสเตอร์ได้อย่างไร? คำถามที่พบบ่อยสำหรับตัวแทนของเว็บสตูดิโอ ใช่เหมือนกันทุกประการ เซิร์ฟเวอร์ปกติ- จะมีเพียงคลัสเตอร์เดียวสำหรับคุณ คอมพิวเตอร์ขนาดใหญ่ซึ่งคุณเข้าสู่ระบบผ่าน ssh ในลักษณะเดียวกันและทำงาน

โมดูลเว็บคลัสเตอร์เป็นการผสมผสานระหว่างโซลูชันทางเทคโนโลยีที่ช่วยให้คุณสามารถกระจายเว็บไซต์หนึ่งไปยังเซิร์ฟเวอร์หลายเครื่องได้ ดังนั้นจึงช่วยแก้ปัญหาหลายประการ: ความพร้อมใช้งานสูงไซต์, ปรับขนาดภายใต้เงื่อนไขของการเพิ่มโหลด, ปรับสมดุลโหลด, การรับส่งข้อมูล, ข้อมูลระหว่างเซิร์ฟเวอร์หลายเครื่อง ด้วยเว็บคลัสเตอร์ คุณจะเพิ่มประสิทธิภาพ ความสามารถในการปรับขนาด และความน่าเชื่อถือของโครงการของคุณได้!

คุณต้องการเว็บคลัสเตอร์สำหรับงานอะไรบ้าง?

คลัสเตอร์เป็นสิ่งจำเป็นในการแก้ปัญหาการเพิ่มภาระงานและเพิ่มเสถียรภาพของบริการอย่างยืดหยุ่น ดังนั้นเมื่อปริมาณการรับส่งข้อมูลเพิ่มขึ้น คุณสามารถเพิ่มเซิร์ฟเวอร์ใหม่ให้กับคลัสเตอร์ได้อย่างรวดเร็ว และหากเซิร์ฟเวอร์คลัสเตอร์ตัวใดตัวหนึ่งล้มเหลว ระบบจะยังคงให้บริการผู้เยี่ยมชม/ลูกค้าอย่างต่อเนื่อง ไม่น้อย งานสำคัญ– นี่คือการปรับสมดุลโหลด การรับส่งข้อมูล ข้อมูลระหว่างเซิร์ฟเวอร์หลายเครื่อง ในขณะเดียวกันระบบก็ให้คุณลบออกได้ การสำรองข้อมูลจากคลัสเตอร์โหนดที่กำหนดเป็นพิเศษ โดยไม่กระทบต่อการทำงานของไซต์งาน โดยไม่ปิดเครื่องหรือทำให้เครื่องช้าลง มีงานแยกจากกันในการกระจายทางภูมิศาสตร์ เมื่อคุณเรียกใช้คลัสเตอร์เว็บทางภูมิศาสตร์ จะช่วยให้คุณสามารถหมุนกลุ่มเซิร์ฟเวอร์ทั้งหมดได้ แต่ละกลุ่มเหล่านี้มีศูนย์ข้อมูลหลักของตนเองแยกจากกัน ดังนั้นเว็บไซต์และธุรกิจของคุณจึงได้รับการปกป้องอย่างสมบูรณ์จากการไม่สามารถเข้าถึงศูนย์ข้อมูลและช่องทางการสื่อสารได้

เว็บคลัสเตอร์ 1C Bitrix ทำงานอย่างไร

มาดูกันว่าเว็บคลัสเตอร์ 1C Bitrix ใช้เทคโนโลยีใดบ้าง:

• สำหรับฐานข้อมูลนี้ก็คือ การแบ่งส่วนแนวตั้ง(การย้ายโมดูลไปแยกกัน เซิร์ฟเวอร์ MySQL)
• การจำลองแบบ MySQLและ โหลดบาลานซ์ระหว่างเซิร์ฟเวอร์
• กระจาย แคชข้อมูล(เมมแคช)
• ความต่อเนื่องของเซสชันระหว่างเว็บเซิร์ฟเวอร์ (จัดเก็บเซสชันในฐานข้อมูล)

การทำคลัสเตอร์เว็บเซิร์ฟเวอร์เกิดขึ้นเนื่องจากการซิงโครไนซ์ไฟล์, การปรับสมดุลโหลดระหว่างเซิร์ฟเวอร์, ความเป็นอิสระทางภูมิศาสตร์จากศูนย์ข้อมูล (ในกรณีที่ศูนย์ข้อมูลแห่งหนึ่งล้มเหลว ศูนย์ข้อมูลอีกแห่งจะเริ่มทำงานทันที โดยไม่จำเป็นต้องเพิ่มการสำรองข้อมูลและการดำเนินการอื่น ๆ นี่คือ การแลกเปลี่ยนความร้อนจริง)

ความลับของการโหลดสูงบน 1C Bitrix พร้อมเว็บคลัสเตอร์

1. การแบ่งกลุ่ม MySQL

การแบ่งฐานข้อมูลแอปพลิเคชันเว็บหนึ่งฐานข้อมูลออกเป็นสองฐานข้อมูลขึ้นไปโดยการแยกโมดูลแยกกัน โดยไม่ต้องเปลี่ยนตรรกะของแอปพลิเคชันเว็บ

โมดูลผลิตภัณฑ์ต่อไปนี้สามารถวางในฐานข้อมูลแยกกันได้: , .

2. การจำลองแบบ MySQL

โครงการ " ทาสนาย»ดำเนินการโดยใช้ MySQL/MariaDB กลุ่มเทคโนโลยีนี้มีการอธิบายไว้ค่อนข้างดีและมีการใช้กันอย่างแพร่หลาย

3. Balancer สำหรับการปรับสมดุลโหลดระหว่างเซิร์ฟเวอร์

มาดูบาลานเซอร์กันดีกว่า 1C-Bitrix: แพลตฟอร์มการจัดการไซต์ในฟังก์ชันการทำงานของเว็บคลัสเตอร์ช่วยให้คุณสร้างสมดุลโหลดระหว่างเซิร์ฟเวอร์ที่เข้าร่วมในการจำลองแบบได้อย่างยืดหยุ่น

เราได้รับสิ่งต่อไปนี้ คุณสมบัติที่สำคัญ: การปรับสมดุลโหลดที่ยืดหยุ่นใน MySQL การดูแลระบบที่ง่ายดายจากอินเทอร์เฟซเดียว รวดเร็ว ปรับขนาดได้ไม่จำกัดไม่มีค่าใช้จ่ายเพิ่มเติม การสำรองข้อมูลแบบ hot (อันที่จริงคือ: การสร้างสำเนาสำรอง รัฐที่แท้จริง- ฟังก์ชันทั้งหมดนี้ไม่จำเป็นต้องมีการแก้ไขตรรกะของแอปพลิเคชันเว็บ ทุกอย่างใช้งานได้แล้วในฉบับนี้

4. แคชข้อมูลที่กระจาย (จัดการโดย: memcached)

เทคโนโลยีช่วยให้ข้อมูลถูกแคชไว้ใน RAM ของหลาย ๆ เซิร์ฟเวอร์ที่มีอยู่- การกระจายจะดำเนินการโดยการแบ่งส่วนข้อมูลตามค่าแฮชของคีย์ คล้ายกับซ็อกเก็ตตารางแฮช ไลบรารีไคลเอนต์ใช้คีย์ข้อมูลคำนวณแฮชและใช้เพื่อเลือกเซิร์ฟเวอร์ที่เหมาะสม

ช่วยให้มั่นใจได้ถึงประสิทธิภาพสูง - เนื่องจากการใช้งานแคชแบบรวมศูนย์โดยเว็บแอปพลิเคชัน เช่นเดียวกับความน่าเชื่อถือ - เนื่องจากความต้านทานของระบบย่อยแคชต่อความล้มเหลว ส่วนประกอบแต่ละส่วนในขณะที่รับประกันความสามารถในการปรับขนาดได้ไม่จำกัดโดยการเพิ่มเซิร์ฟเวอร์ memcached ใหม่เมื่อปริมาณงานเพิ่มขึ้น

5. ความต่อเนื่องของเซสชัน

ในการจัดระเบียบความต่อเนื่องของเซสชันระหว่างเว็บเซิร์ฟเวอร์ จำเป็นต้องเปิดใช้งานการจัดเก็บเซสชันในฐานข้อมูล และฐานข้อมูลจะถูกจำลองแบบตามที่ระบุไว้ข้างต้น

ความสามารถในการจัดเก็บข้อมูลเซสชั่นของผู้ใช้ในฐานข้อมูลทำให้มั่นใจได้ถึง “ความโปร่งใส” ของเซสชั่นสำหรับเว็บเซิร์ฟเวอร์ทั้งหมดในคลัสเตอร์ เนื่องจาก หลังจากการอนุญาตบนเซิร์ฟเวอร์ตัวใดตัวหนึ่ง ผู้ใช้จะต้องได้รับการพิจารณาว่าได้รับอนุญาตสำหรับเซิร์ฟเวอร์อื่นทั้งหมด และในทางกลับกัน หลังจากสิ้นสุดเซสชันบนเซิร์ฟเวอร์ใดๆ ก็ควรหมายถึงการสิ้นสุดเซสชันบนเซิร์ฟเวอร์ทั้งหมดในครั้งเดียว

สวัสดีผู้สมรู้ร่วมคิด!

บทความนี้เกี่ยวกับวิธีที่เราใช้เว็บคลัสเตอร์ พอร์ทัลข่าว(ด้วยยอดเข้าชม 130,000 ครั้ง ผู้เยี่ยมชมที่ไม่ซ้ำใครต่อวัน - นี่คือการรับส่งข้อมูล 7TB เป็นเวลา 3 วัน - การเลือกตั้งและ 2 ครั้งต่อมา โดยเฉลี่ยแล้ว คลัสเตอร์จะกระจายการรับส่งข้อมูล 35-40 TB ต่อเดือน) เกี่ยวกับวิธีที่โปรแกรมเมอร์และนักข่าวเข้าใจงานเดียวกันแตกต่างกันอย่างไร คุณสามารถบรรลุเป้าหมายเดียวกันด้วยเส้นทางที่แตกต่างกันได้อย่างไร

มันจะเป็นที่สนใจสำหรับผู้ที่ต้องการสร้างเว็บคลัสเตอร์ที่ปรับขนาดได้ง่ายและกระจายตามภูมิศาสตร์โดยไม่ต้องลงทุนจำนวนมหาศาลในอุปกรณ์ (และตามมาตรฐานโทรทัศน์ จำนวนเงินโดยทั่วไปจะไร้สาระ)

ฉันแน่ใจมากกว่าว่านักการตลาดที่ผลักดันโซลูชัน Uber สำหรับผลิตภัณฑ์ออกใหม่ที่มีคำว่า "scalable web cluster" หรือ "horizontal infinite scalable web cluster" ในชื่อของพวกเขาจะเกลียดฉัน

ฉันมั่นใจอย่างยิ่งว่าคู่แข่งของลูกค้าของเราจะต้องประหลาดใจกับความเรียบง่ายของโซลูชันที่เราใช้

ฉันจะไม่ให้การกำหนดค่าซ้ำ ๆ ที่สามารถพบได้ในบทช่วยสอนใด ๆ การตั้งค่า PHP, Nginx และ Firebird (อย่างหลังพูดอย่างเคร่งครัดไม่มีอะไรต้องกำหนดค่า - ทุกอย่างใช้งานได้นอกกรอบ) และโดยทั่วไปฉันจะพูดถึงสาระสำคัญของการแก้ปัญหาไม่ใช่เกี่ยวกับอันไหน เวอร์ชัน PHPดีกว่า.

นักออกแบบที่มีประสบการณ์ไม่น่าจะสนใจ - พวกเขารู้ทุกอย่างอยู่แล้ว แต่สำหรับผู้ที่เพิ่งเริ่มต้นในด้านการออกแบบระบบที่ยากลำบากนั้นยากกว่า "Hello, World!" จะมีบางสิ่งที่ต้องเรียนรู้อย่างแน่นอน - วิธีแก้ปัญหาอยู่ในโหมดการต่อสู้มาเกือบ 2 ปีแล้วและไม่มีปัญหาทางสถาปัตยกรรมเกิดขึ้น (แม้ว่าความล้มเหลวของทั้งสองในคราวเดียว ฮาร์ดไดรฟ์อยู่บนสองในสามโหนด แต่ไม่มีใครสังเกตเห็นอะไรเลย - ไซต์เปิดช้ากว่าปกติเล็กน้อย)

สองสามคำเกี่ยวกับเรื่องทั้งหมดเริ่มต้นขึ้น กาลครั้งหนึ่งมีเว็บไซต์ของกลุ่มนักข่าวอิสระที่ฝันอยากเป็นโทรทัศน์จริงๆ (เมื่อมองไปข้างหน้าฉันจะบอกว่าพวกเขาประสบความสำเร็จ - พวกเขาสร้างโทรทัศน์ของตัวเองที่ประสบความสำเร็จค่อนข้างมากด้วย "แบล็คแจ็คและ ... " - เพิ่มเติมในข้อความ) ประเทศของเรามีขนาดเล็ก ไม่มีอะไรเลวร้ายเกิดขึ้น (และเราพอใจกับมัน) แต่ทุกๆ 4 ปี เราจะมีการเลือกตั้งรัฐสภาตามธรรมเนียม ซึ่งโดยธรรมเนียมแล้วไม่ได้เลือกประธานาธิบดีแต่อย่างใด (ไม่ต้องกลัวไม่มีการเมืองที่นี่มีไว้เพื่อ. ความเข้าใจร่วมกันช่วงเวลา).

แน่นอนว่าในช่วงก่อนการเลือกตั้งและหลังจากนั้นเล็กน้อยสื่อออนไลน์ทั้งหมดมีความไม่แน่นอนอย่างมาก เว็บไซต์บางแห่งไม่เพียงแค่วางอยู่ตรงนั้น แต่ยังวางอยู่รอบ ๆ บางไซต์พยายามจัดเตรียมข้อความอย่างน้อยหนึ่งบรรทัดเป็นระยะ ๆ แต่ปัญหานั้นเป็นสากลและเป็นที่รู้จัก - ไซต์ไม่สามารถรับมือกับการไหลเข้าของผู้เข้าชมได้ ฉันกำลังพูดถึงเว็บไซต์แบบข้อความทั่วไป และลูกค้าของเราก็มีเว็บไซต์ที่ไม่ธรรมดา ความจริงก็คือพวกเขายังมีวิดีโอด้วย - ข่าว พวกเขาผลิตได้ 10 กิกะไบต์ต่อเดือน - ในเวลานั้นพวกเขาสร้างวิดีโอมากมายขนาดนั้นต่อวัน เหนือสิ่งอื่นใด (นี่คือการกล่าวถึงการเมืองครั้งสุดท้าย) นักข่าวเหล่านี้ไม่ได้จงรักภักดีต่อเจ้าหน้าที่เป็นพิเศษ พวกเขาพูดและเขียนสิ่งที่พวกเขาต้องการ ค่อนข้างหยาบคายใช่ไหม? เราวางตำแหน่งตัวเองเป็นทหารรับจ้างเสมอ - ลูกค้าเสนอปัญหา เราเสนอวิธีแก้ปัญหา ทุกสิ่งทุกอย่างไม่สนใจเรา เรารักษาความเป็นกลาง

เราได้รับมอบหมายงานในการนำเสนอโซลูชั่นสำหรับเว็บไซต์ข่าวที่ไม่เพียงแต่จะต้านทานการไหลเข้าของผู้เข้าชม 50-100,000 คนเท่านั้น แต่ยังกระจัดกระจายทางภูมิศาสตร์ทั่วโลกและควบคุมจากบังเกอร์เคลื่อนที่ทุกที่ในจักรวาลบน ดาวเคราะห์. แน่นอนว่าการกระจายตัวทางภูมิศาสตร์ของโหนดคลัสเตอร์เป็นหน้าที่ของเรา ด้วยเหตุนี้ เราจึงเสนอรูปแบบดังต่อไปนี้ (ฉันไม่ใช่ศิลปินมากนัก หากคุณต้องขออภัย):

(นี้ แผนภาพแบบง่ายในเดือนพฤศจิกายน เซิร์ฟเวอร์เกือบทั้งหมดถูกโอนไปยัง Hetzner ในเวลาต่อมา เนื่องจากในเวลานั้นช่องของ Netdirekt ประสบปัญหาอยู่ตลอดเวลา ตอนนี้สถานการณ์กับเครือข่ายดีขึ้นมาก)
ผู้เยี่ยมชมทั่วไปจะเห็นหนึ่งใน 3 เซิร์ฟเวอร์ ในขณะที่เราทำเพื่อให้ผู้เยี่ยมชมทั้งหมดจากมอลโดวาดึงเนื้อหา "เล็กน้อย" ในรูปแบบของข้อความและรูปภาพจากหนึ่งใน 3 เซิร์ฟเวอร์ และดึงเนื้อหา "หนัก" (วิดีโอ) จากเซิร์ฟเวอร์ที่ตั้งอยู่ในท้องถิ่น ผู้ให้บริการ ผู้เยี่ยมชมภายนอกไม่เห็นกระจกมอลโดวาและดึงเนื้อหาทั้งหมดจากเซิร์ฟเวอร์เยอรมันแห่งใดแห่งหนึ่ง

นี่คือสิ่งที่เราได้รับจากผู้เยี่ยมชม (แต่ละส่วนของพอร์ทัลมีตัวนับของตัวเอง):

รูปแบบนี้ช่วยให้คุณสามารถเปลี่ยนเซิร์ฟเวอร์ควบคุมได้ตลอดเวลา โดยจะตรวจสอบความพร้อมใช้งานของโหนดคลัสเตอร์ และปรับขนาดได้อย่างง่ายดาย - Amazon EC ยังถือเป็นการสำรองข้อมูล - ยิ่งไปกว่านั้น Amazon EC ยังถูกใช้มาระยะหนึ่งสำหรับการสตรีมวิดีโอ ( ประมาณ 4 เดือน) แต่เนื่องจากค่าใช้จ่ายในการรับส่งข้อมูลสูง จึงตัดสินใจโอนโหนดสตรีมมิ่งไปยัง German Hetzner
2 สัปดาห์ก่อนชั่วโมง "X" ที่เราถ่าย เซิร์ฟเวอร์สำรองและทำให้พวกเขาพร้อม (แต่ผู้ใช้ไม่เห็นพวกเขาเนื่องจากการทำให้เซิร์ฟเวอร์ใช้งานได้นั้นค่อนข้างถูกกว่าการใช้ในโหมดการต่อสู้ - เนื่องจากการรับส่งข้อมูลเท่านั้น)

มันทำงานอย่างไร? ง่ายมาก - เงียบ ๆ และตลอดเวลา;)

บนเซิร์ฟเวอร์ควบคุม (ดังที่ฉันได้กล่าวไปแล้วพอร์ทัลมี "ส่วน" ขนาดใหญ่ 2 ส่วน: ข่าวในรูปแบบของข้อความพร้อมรูปภาพและข่าวในรูปแบบของการแยกข้อความและวิดีโอ โดยพฤตินัยมีการใช้เซิร์ฟเวอร์ 2 เครื่อง แต่เพื่อความเรียบง่าย ฉันอธิบายไว้อย่างหนึ่ง) มีบางสิ่งที่เรียกกันทั่วไปว่าระบบการจัดการเนื้อหา

วัตถุประสงค์หลักของเซิร์ฟเวอร์นี้คือเพื่อให้นักข่าวสามารถเพิ่มข่าวสารได้ ทุกครั้ง เวลาที่แน่นอน(3-5 นาที) สคริปต์เริ่มทำงาน ซึ่งสร้าง... สำเนาออฟไลน์ของไซต์ แน่นอนว่าเฉพาะหน้าที่มีการเปลี่ยนแปลงหรือจำเป็นต้องสร้างใหม่เนื่องจากการเชื่อมโยงข้ามและการขึ้นต่อกันเท่านั้นที่ถูกสร้างขึ้น

นี่เป็นเรื่องง่ายมากที่จะนำไปใช้โดยใช้ลำดับและทริกเกอร์แบบเรียงซ้อนใน Firebird - ขั้นตอนจำเป็นต้องทำการเปลี่ยนแปลงในหน้าหลักของไซต์เท่านั้น และทริกเกอร์แบบเรียงซ้อนจะอัปเดตการอ้างอิงทั้งหมด โดยทำเครื่องหมายแต่ละหน้าที่ต้องการอัปเดต เครื่องหมายไม่ได้กำหนดไว้ในรูปแบบธง 1/0 แต่อยู่ในรูปแบบ หมายเลขที่ไม่ซ้ำได้มาบนพื้นฐานของเครื่องกำเนิด สคริปต์สำหรับการสร้างเวอร์ชันออฟไลน์เมื่อเริ่มต้นระบบจะจดจำค่าใหม่ของตัวสร้าง อ่านค่าของตัวสร้างนี้จากการเปิดตัวครั้งก่อน และสร้างเพจทั้งหมดใหม่ในช่วงผลลัพธ์ ในเวลาเดียวกัน เนื่องจากเราใช้กลไกการทำธุรกรรมของ Firebird สคริปต์จึงไม่สนใจว่าการเปลี่ยนแปลงใดจะเกิดขึ้นระหว่างการดำเนินการ - เช่น เราสร้างเว็บไซต์เวอร์ชันที่สอดคล้องกันและสม่ำเสมอเสมอ ไม่ว่านักข่าวจะทำอะไรก็ตาม

ดังนั้นเราจึงสร้างสำเนาหลักของพอร์ทัล (หรือสองพอร์ทัลหากคุณต้องการ - ข้อความและวิดีโอ) สคริปต์ (เช่นเดียวกับแผงผู้ดูแลระบบ) เขียนด้วย PHP และใช้ ADODB เพื่อทำงานร่วมกับ Firebird ดังนั้นจึงสามารถสร้างใหม่ได้อย่างง่ายดายตามคำขอของลูกค้า*

(* แต่เรากำลังจะกำจัด ADODB เร็วๆ นี้ในโครงการทั้งหมดในอนาคตของเรา - ความเป็นสากลของมันส่งผลเสียต่อกลไกปกติในการทำงานกับฐานข้อมูลเท่านั้น ทำให้คุณสามารถใช้คุณสมบัติทั้งหมดของ Firebird ได้ เซิร์ฟเวอร์ SQL(แต่เช่นเดียวกับวิธีอื่นๆ) ไม่ได้ถูกนำมาใช้ที่นั่น - ตัวอย่างเช่น ไม่สามารถจับข้อยกเว้นได้เมื่อสุ่มตัวอย่างจากขั้นตอนการคัดเลือก ไม่ การจัดการที่ยืดหยุ่นธุรกรรม และโดยทั่วไปแล้ว คลาสเหล่านี้มี AI มากเกินไป - ฉันชอบตัดสินใจด้วยตัวเองว่าต้องการย้อนกลับธุรกรรมเมื่อใด และจะยืนยันเมื่อใด)

สิ่งเดียวที่ต้องเปลี่ยนในการตั้งค่า Firebird คือค่าของขนาดแคชเพจฐานข้อมูล - เนื่องจากจำนวนการเชื่อมต่อกับฐานข้อมูลมีขนาดเล็กมาก (ไม่ค่อยมากกว่า 50-60 การเชื่อมต่อพร้อมกัน) จากนั้นทดลองเพิ่มจำนวนหน้าเป็น 2048 (เราใช้เวอร์ชันคลาสสิก สำหรับสถาปัตยกรรม Super ค่านี้สามารถเพิ่มได้อย่างง่ายดาย 10 เท่า เนื่องจากมีแคชหน้าทั่วไป ใน Firebird 3.0 เวอร์ชันที่กำลังจะมาถึง นักพัฒนาสัญญาว่าสถาปัตยกรรมที่เป็นมิตรกับ SMP หนึ่งรายการด้วย แคชที่ใช้ร่วมกันดังนั้นจึงเป็นไปได้ที่จะใช้ค่าขนาดใหญ่สำหรับการตั้งค่าแคชของหน้า)

จากนั้น เมื่อใช้ rsync แบบปกติ ความแตกต่างในการเปลี่ยนแปลงจะกระจายไปตามกระจก ซึ่งได้แก่ โหนดปกติสำหรับการกระจายไฟล์คงที่ตาม Nginx ฉันคิดว่าไม่จำเป็นต้องบอกคุณว่าเซิร์ฟเวอร์ 4 คอร์ที่มี RAM ขนาด 12 GB สามารถกระจายเฉพาะข้อมูลคงที่ได้อย่างไร -

ในเวลาเดียวกัน 10% ของช่องสัญญาณของแต่ละโหนด (ซึ่งก็คือ 10 หรือ 100 เมกะบิตขึ้นอยู่กับ การเชื่อมต่อเฉพาะ) สงวนไว้สำหรับการซิงโครไนซ์ การซิงโครไนซ์เกิดขึ้นใน 2 ขั้นตอน - ขั้นแรก เนื้อหา "หนัก" จะถูกซิงโครไนซ์ - รูปภาพและวิดีโอ จากนั้น - ข้อความ (html/xml/js)

บางครั้ง (เมื่อช่องสัญญาณจากเซิร์ฟเวอร์ควบคุมไปยังมิเรอร์ไม่ว่าง) ผู้เยี่ยมชมอาจเห็นความไม่สอดคล้องกันเล็กน้อยในรูปแบบของรูปภาพและ/หรือวิดีโอที่ไม่โหลด - เนื่องจากมีการใช้ DNS แบบ Round-robin ผู้ใช้สามารถรับข้อความของ หน้าจากมิเรอร์หนึ่ง และลิงก์ไปยังวิดีโอจากอีกมิเรอร์ สิ่งนี้ไม่ได้ป้องกันพอร์ทัลไม่ให้ทำงาน - ข้อความจะอยู่ที่นั่นเสมอและรูปภาพหรือวิดีโอจะปรากฏขึ้นไม่ช้าก็เร็ว

เนื่องจากไซต์มีรูปแบบแบบไดนามิก - ตัวอย่างเช่นสมัครรับจดหมายข่าว - แบบฟอร์มเหล่านี้จึงได้รับการประมวลผลโดยเซิร์ฟเวอร์เฉพาะที่แยกต่างหาก (ไม่แสดงในแผนภาพ แต่สิ่งนี้จะไม่เปลี่ยนสาระสำคัญ) แม้ว่าเราจะถือว่าผู้เยี่ยมชมทุกคนรีบสมัครรับข่าวสารในเวลาเดียวกันและเซิร์ฟเวอร์นี้ล่ม แต่ก็ไม่มีอะไรเลวร้ายเกิดขึ้น - แบบฟอร์มจะถูกโหลดลงใน iframe และการไม่มีแบบฟอร์มเหล่านี้ก็ไม่ส่งผลกระทบต่อความพร้อมใช้งานของข่าวสาร

การเพิ่มโหนดใหม่นั้นง่ายดาย - ขั้นแรกมิเรอร์ใหม่จะถูกซิงโครไนซ์กับสำเนาหลัก (สิ่งนี้เกิดขึ้นควบคู่ไปกับการทำงานปกติของซิงโครไนเซอร์) จากนั้นรายการจะถูกเพิ่มลงใน DNS และ... ไม่มีใครสังเกตเห็นอะไรเลย

การลบโหนดนั้นง่ายกว่า - เพียงแค่ลบรายการออกจาก DNS การเพิ่มและการลบค่อนข้างคล้อยตามระบบอัตโนมัติ (นี่คือสิ่งที่เราทำกับส่วนที่รับผิดชอบในการสตรีมเว็บประมาณ 1,000 เมกะบิตสตรีมบน Amazom EC) แต่ถ้าคุณตัดสินใจทำซ้ำโดยกะทันหัน ฉันแนะนำให้คุณคำนวณก่อนว่าอย่างไร การซิงโครไนซ์ข้อมูลเริ่มต้นใช้เวลามาก (สำหรับเราคือ 2 กิกะไบต์สำหรับ " รุ่นเบาพอร์ทัล" และประมาณ 1 เทราไบต์สำหรับวิดีโอ มีเพียงบางส่วนเท่านั้นที่ถูกเก็บไว้ เดือนที่ผ่านมา).

นั่นคือเหตุผลที่เราลบการเพิ่ม/การลบโหนดแบบไดนามิกออกจากพูลสำรองหลังจากผ่านไประยะหนึ่งของโปรเจ็กต์ - เนื้อหากินมากเกินไปและสคริปต์กลายเป็นหวาดระแวงเกินไป - มันจะลบโหนดทุกครั้งที่มีปัญหาในการสื่อสารกับพวกเขา .

แยกกันเป็นมูลค่าการกล่าวขวัญถึงการคำนวณการแสดงข่าว ฉันรู้สึกว่างานอดิเรกโปรดของนักข่าว (นอกเหนือจากการเขียน/การถ่ายทำรายงาน) กำลังวัดจำนวนผู้เข้าชมข่าวเรื่องใดเรื่องหนึ่ง เราต้องใช้เลือดประมาณหนึ่งลิตรและความกังวลหนึ่งกิโลเมตรเพื่อโน้มน้าวสมาคมนักข่าวว่าไม่จำเป็นต้องแสดงการเปลี่ยนแปลงแบบเรียลไทม์

โปรแกรมเมอร์เข้าใจดีว่าการค้นหาว่ามีกี่คน ช่วงเวลาปัจจุบันการอ่านบทความเป็นไปไม่ได้เลย คุณสามารถนับจำนวนคำขอบทความจากเซิร์ฟเวอร์ได้เท่านั้น แต่สำหรับนักข่าว นี่เป็นแนวคิดเดียวกัน -

เพื่อนับจำนวนการดู เราได้ติดต่อกับ Kiril Korinsky (หรือที่เรียกว่า catap) ซึ่งยินดีที่จะเพิ่มคุณลักษณะการนับการดู URL ให้กับสาขา Nginx ของเขา ถ้าอย่างนั้นทุกอย่างก็ง่าย - โหนดทั้งหมดจะถูกสำรวจเป็นระยะและตัวนับหน้าจะถูกนำมาพิจารณาในคุณสมบัติของหน้านั้นเอง เนื่องจากตัวนับ (เช่นค่าของตัวเอง) ถูกเก็บไว้ใน แยกไฟล์(ปัจจุบันเป็นหนึ่งไฟล์ต่อข่าว ในไม่ช้า เราวางแผนที่จะสร้างกลุ่มตัวนับในไฟล์เดียวเพื่อลดจำนวนไฟล์เอง) - จากนั้นในระหว่างการซิงโครไนซ์ ไม่ใช่ทั้งหน้าไซต์จะถูกถ่ายโอน แต่จะมีเพียงไฟล์ตัวนับเท่านั้น ด้วยไฟล์จำนวนมากสิ่งนี้จะสร้างภาระเพิ่มเติมบนระบบย่อยของดิสก์ - ดังนั้นเมื่อใช้วิธีการเดียวกันให้คิดทันทีว่าจะแบ่งตัวนับออกเป็นกลุ่มได้อย่างไร - เราตกลงที่จะแบ่งตัวนับตามประเภทและวันที่ของข่าว - ไฟล์ มีขนาดค่อนข้างเล็กและเมื่อเวลาผ่านไปพวกเขาก็หยุดเปลี่ยนแปลง เนื่องจากในทางปฏิบัติไม่มีใครสนใจข่าวเก่า

โดยสรุปคือข้อดีของโซลูชันที่เราใช้:

1. การใช้ไซต์แบบคงที่เป็นโหนดคลัสเตอร์ของเว็บช่วยให้คุณสามารถลดการดูแลคลัสเตอร์ทั้งหมดเหลือเพียงเล็กน้อย งานประจำ- อัปเดต ระบบปฏิบัติการโหนดและการชำระเงินการรับส่งข้อมูล จุดเดียวกันนี้ทำให้คุณสามารถกระจายโหนดคลัสเตอร์ทางภูมิศาสตร์ได้ ซึ่งเมื่อรวมกับ GEO-DNS แล้ว ถือได้ว่าเป็นอะนาล็อกบางประเภทของเครือข่ายการจัดส่งเนื้อหา (CDN) - อันที่จริงแล้ว นั่นคือสิ่งที่เป็นอยู่
2. การใช้กลไกการทำธุรกรรมของฐานข้อมูลและการถ่ายโอนลอจิกไปยังฐานข้อมูลนั้นทำให้คุณสามารถมีไซต์เวอร์ชันองค์รวมและตรรกะที่สอดคล้องกันอยู่เสมอ - อย่างไรก็ตาม ฉันจะแปลกใจมากถ้า "ส่วน" ของข้อมูลจากเซิร์ฟเวอร์ไม่สอดคล้องกันในเชิงตรรกะ .
3. หากคาดว่าจะมีผู้มาเยือนหลั่งไหลเข้ามาแล้ว การขยายอย่างง่ายโหนดคลัสเตอร์สามารถจัดการได้อย่างง่ายดาย ในกรณีของเรา อินพุตเต็มโหนดใหม่ใช้เวลาประมาณหนึ่งชั่วโมงกว่าจะเริ่มทำงานสำหรับส่วนข้อความของพอร์ทัลและประมาณหนึ่งวัน (คุณไม่สามารถใส่สิ่งที่ไม่สามารถบีบเข้าไปได้) สำหรับวิดีโอ หากคุณยอมรับการซิงโครไนซ์ไซต์บางส่วนและเพิ่มส่วนที่เหลือในพื้นหลัง การป้อนโหนดใหม่สำหรับวิดีโอก็สามารถลดลงเหลือหนึ่งชั่วโมงได้เช่นกัน
4. เซิร์ฟเวอร์การดูแลระบบสามารถสร้างได้จากโหนดใดก็ได้ (หากจำเป็น) - เพียงแค่ปรับใช้มัน การสำรองฐานข้อมูล(บีบอัดประมาณหนึ่งร้อยเมกะไบต์) เนื้อหาอื่นๆ ทั้งหมดมีอยู่แล้ว

มีข้อเสียอยู่สองสามข้อเพื่อที่จะไม่ใช่ทุกอย่างที่ดูเป็นสีดอกกุหลาบ:

1. วิธีแก้ไขไม่เหมาะกับกรณีที่มีบางส่วนของไซต์ที่ควรมองเห็นแตกต่างออกไป ผู้ใช้ที่แตกต่างกัน, เช่น. เมื่อตามเงื่อนไขของงาน เพจจะถูกสร้างขึ้นเป็นการส่วนตัวสำหรับผู้ใช้แต่ละคน ในกรณีของเรา สิ่งนี้กลายเป็นเรื่องไม่จำเป็น
2. เคาน์เตอร์ผู้เยี่ยมชมได้รับการอัปเดตโดยล่าช้าประมาณครึ่งชั่วโมงถึงหนึ่งชั่วโมง ทนได้ แต่คุณจะต้องโน้มน้าวลูกค้าในเรื่องนี้เป็นเวลานาน
3. ปัญหาที่ใหญ่ที่สุดคือการซิงโครไนซ์กับมิเรอร์ในเครื่อง - ผู้ให้บริการของเรายังไม่ได้ขายการรับส่งข้อมูลในราคา 7 ยูโรต่อเทราไบต์ และแม้ว่าพวกเขาจะมอบ 100 เมกะบิตที่เที่ยงตรงให้กับโลก แต่ก็ในราคาที่ไม่เพียงพออย่างมาก
4. ออกแบบระบบที่หวาดระแวงน้อยลงสำหรับการติดตามโหนดคลัสเตอร์ - ระบบของเราไวเกินไป เราต้องเพิ่มและลบโหนดในโหมดแมนนวล

และประสบการณ์เล็กๆ น้อยๆ ที่จะช่วยเพิ่มความหลากหลายให้กับความวุ่นวายในชีวิตประจำวัน

เราใช้ระบบไฟล์ JFS เพื่อจัดเก็บสำเนาออฟไลน์ของไซต์ มันพิสูจน์ตัวเองได้ดีมากทั้งเมื่อทำงานกับไฟล์ขนาดเล็กจำนวนมากและเมื่อทำงานกับ ไฟล์ขนาดใหญ่(จากประสบการณ์ของผม มีเพียง XFS เท่านั้นที่สามารถลบไฟล์ขนาด 200-300GB ได้แทบจะในทันที)

นี่คือค่าเริ่มต้น ระบบไฟล์ติดตั้งด้วยพารามิเตอร์เริ่มต้น แต่เนื่องจากเรามีไฟล์จำนวนมากเมื่อเวลาผ่านไป การดำเนินงานของดิสก์พวกเขาเริ่มช้าลงเล็กน้อย ตั้งแต่เวลา การเข้าถึงครั้งสุดท้ายเราไม่ต้องการมันลงในไฟล์ ฉันเพิ่มตัวเลือก "noatime" ให้กับพารามิเตอร์การเมานต์ FS นี่คือสิ่งที่เกิดขึ้น - ฉันคิดว่าคุณสามารถตัดสินใจได้ด้วยตัวเองว่าจะเพิ่มเมื่อใด:

ฉันขอย้ำสั้น ๆ - สำหรับ การดำเนินงานที่มั่นคงวี โหมดปกติใช้แล้ว:

• 3 เซิร์ฟเวอร์สำหรับการเผยแพร่เนื้อหา
• 2 เซิร์ฟเวอร์สำหรับ “ผู้ดูแลระบบ”
• 2 เซิร์ฟเวอร์สำหรับ DNS และระบบติดตามสำหรับเซิร์ฟเวอร์อื่น

โหนดคลัสเตอร์กระจัดกระจายตามภูมิศาสตร์และอยู่ที่ผู้ให้บริการหลายราย
ในกรณีที่มีเหตุการณ์ที่คาดว่าจะดึงดูด จำนวนมากผู้เยี่ยมชม - เชื่อมต่อ เซิร์ฟเวอร์เพิ่มเติมเพื่อเผยแพร่เนื้อหา

ปริมาณการใช้งานประมาณ 40TB ต่อเดือน ปริมาณรวมเนื้อหา - เพียง 1 เทราไบต์ เนื้อหาวิดีโอจะถูกเก็บไว้ประมาณ 3 เดือน

ฉันยินดีที่จะตอบคำถามจากชุมชนฮาบรา

1C-Bitrix: เว็บคลัสเตอร์ งานหลักที่ต้องแก้ไข: 1. ตรวจสอบให้แน่ใจว่ามีความพร้อมใช้งานสูงของบริการ (ที่เรียกว่า HA - ความพร้อมใช้งานสูงหรือคลัสเตอร์ล้มเหลว) 2. ปรับขนาดโครงการเว็บภายใต้เงื่อนไขของโหลดที่เพิ่มขึ้น (HP - คลัสเตอร์ประสิทธิภาพสูง) 3. ปรับสมดุลโหลด การรับส่งข้อมูล ข้อมูลระหว่างเซิร์ฟเวอร์หลายเครื่อง 4.สร้างสำเนาสำรองข้อมูลที่สมบูรณ์สำหรับ MySQL

1C-Bitrix: เว็บคลัสเตอร์ “เว็บคลัสเตอร์” ช่วยให้มั่นใจถึงความต่อเนื่องทางธุรกิจ ความทนทานต่อข้อผิดพลาด การปรับขนาด การกระจายโหลด โครงการใหม่หรือโครงการที่กำลังดำเนินการอยู่บน 1C-Bitrix: Site Management 10.0 สามารถนำเสนอเป็นเว็บคลัสเตอร์ของเซิร์ฟเวอร์ที่เปลี่ยนกันได้ 1.เมื่อปริมาณการรับส่งข้อมูลเพิ่มขึ้น คุณสามารถเพิ่มเซิร์ฟเวอร์ใหม่ให้กับคลัสเตอร์ได้อย่างรวดเร็ว 2.หากเซิร์ฟเวอร์คลัสเตอร์ตัวใดตัวหนึ่งล้มเหลว ระบบจะยังคงให้บริการลูกค้าอย่างต่อเนื่อง 3.โหลดบาลานซ์ การรับส่งข้อมูล ข้อมูลระหว่างเซิร์ฟเวอร์หลายตัว 4.ระบบอนุญาตให้คุณสำรองข้อมูลจากโหนดคลัสเตอร์ที่กำหนดเป็นพิเศษ โดยไม่กระทบต่อการทำงานของไซต์

ประวัติความเป็นมาของประสิทธิภาพของแพลตฟอร์ม จนถึงปี 2548 ปัญหาด้านประสิทธิภาพไม่ได้รับการแก้ไขอย่างเป็นระบบเป็นเวลาหนึ่งปี - ประสิทธิภาพกลายเป็นงานสำคัญสำหรับการพัฒนา ปี - การเกิดขึ้นของเครื่องมือสำหรับการดีบักคำสั่ง SQL การทำงานอย่างเป็นระบบเกี่ยวกับประสิทธิภาพผลิตภัณฑ์ปี – ก่อน การทดสอบโหลดด้วย QSOFT (1.5 ล้าน Hit ต่อวันในรุ่น “Business”, 6 ล้านครั้งในรุ่น “Start”) ปี – ปรับใช้การกำหนดค่า Oracle RAC 4 รายการพร้อมเซิร์ฟเวอร์ 4 ปี – “การตรวจสอบประสิทธิภาพ” ในทุกรุ่นของปีผลิตภัณฑ์ – “1C ” เปิดตัว -Bitrix: เครื่องเสมือน" และ "1C-Bitrix: สภาพแวดล้อมเว็บ" - ปีการรับรองผู้ให้บริการโฮสติ้ง - การเติบโตของประสิทธิภาพ - เพิ่มขึ้น 430%! การทดสอบโหลดใหม่: 8.5 ล้านครั้ง – “ธุรกิจ”, 12.4 ล้าน – “เริ่มต้น”, 85 ล้าน – “แคช HTML”

ตัวเลือกสำหรับการขยายขนาดเป็นแยกออกเป็นสองเซิร์ฟเวอร์: เว็บเซิร์ฟเวอร์ + ฐานข้อมูล 2.การเพิ่มพลังของอุปกรณ์ (ยิ่งแรง ยิ่งแพง ต้นทุนที่เพิ่มขึ้นไม่เป็นสัดส่วน) 3. การจัดสรรแคชเป็นหนึ่ง เซิร์ฟเวอร์ภายนอกผ่าน memcached 4. การเปลี่ยนไปใช้ Oracle (ใบอนุญาตขั้นต่ำ +5,000 ดอลลาร์ต่อโปรเซสเซอร์) 5. การสร้าง Oracle RAC (คลัสเตอร์แอปพลิเคชันจริง) โครงการ – ประมาณ $ (อุปกรณ์ + ใบอนุญาต + “ชั้นวางที่ใช้ร่วมกัน”) มีผู้เชี่ยวชาญน้อยมาก สำหรับไคลเอนต์ส่วนใหญ่ ประสิทธิภาพก็เพียงพอแล้ว แต่ปัญหาของความทนทานต่อข้อผิดพลาด ความซ้ำซ้อน และความพร้อมใช้งานของเครือข่ายยังไม่ได้รับการแก้ไข

1C-Bitrix: เว็บคลัสเตอร์ “1C-Bitrix: เว็บคลัสเตอร์” เป็นการผสมผสานระหว่างเทคโนโลยี: การแบ่งส่วนแนวตั้ง (การกระจายโมดูลไปยัง เซิร์ฟเวอร์แยกต่างหาก MySQL) การจำลองแบบ MySQL (Oracle และ MS SQL ในอนาคต) และการปรับสมดุลโหลดระหว่างเซิร์ฟเวอร์ แคชข้อมูลแบบกระจาย (memcached) ความต่อเนื่องของเซสชันระหว่างเว็บเซิร์ฟเวอร์ (การจัดเก็บเซสชันในฐานข้อมูล) การทำคลัสเตอร์เว็บเซิร์ฟเวอร์: – การซิงโครไนซ์ไฟล์ – การปรับสมดุลโหลดระหว่างเซิร์ฟเวอร์

การแบ่งฐานข้อมูลแอปพลิเคชันเว็บหนึ่งฐานข้อมูลออกเป็นสองฐานข้อมูลขึ้นไปโดยการแยกโมดูลแยกกัน โดยไม่ต้องเปลี่ยนตรรกะของแอปพลิเคชันเว็บ: การค้นหาการวิเคราะห์เว็บ 1. การกระจายโหลดที่มีประสิทธิภาพ 2. การปรับขนาด 3.การแยกจากกัน ปริมาณมากข้อมูล. การแบ่งส่วนแนวตั้ง

ฐานเว็บเซิร์ฟเวอร์ ข้อมูลมายเอสคิวแอลแอปพลิเคชันเว็บ โหลดสูง: ~10^3 เขียน/วินาที ~10^4 อ่าน/วินาที ปริมาณข้อมูลสูง 1) คำขอได้รับการประมวลผลโดยเซิร์ฟเวอร์ DBMS เดียวเท่านั้น 2) CPU และ ระบบย่อยของดิสก์ DBMS - การปรับขนาดมากเกินไปด้วยการเพิ่มโหลด MySQL

ประสิทธิภาพสูง - เนื่องจากการใช้แคชแบบรวมศูนย์ แอปพลิเคชันเว็บความน่าเชื่อถือ - เนื่องจากระบบย่อยแคชมีความต้านทานต่อความล้มเหลวของแต่ละส่วนประกอบ ความสามารถในการปรับขนาดได้ไม่จำกัด - เนื่องจากการเพิ่มเซิร์ฟเวอร์ memcached ใหม่ memcached 1 memcached 2 memcached 3 เว็บคลัสเตอร์ "1C-Bitrix" 40%30% เว็บเซิร์ฟเวอร์ แคชข้อมูลที่กระจาย (memcached)

ความต่อเนื่องของเซสชันระหว่างเว็บเซิร์ฟเวอร์ เซสชันผู้ใช้ควร "โปร่งใส" ไปยังเซิร์ฟเวอร์ทั้งหมด คลัสเตอร์เว็บ- 1.หลังจากการอนุญาตบนเซิร์ฟเวอร์ใดเซิร์ฟเวอร์หนึ่งแล้ว ผู้ใช้จะต้องได้รับการพิจารณาว่าได้รับอนุญาตสำหรับเซิร์ฟเวอร์อื่นๆ ทั้งหมด 2. และในทางกลับกัน - การสิ้นสุดเซสชันบนเซิร์ฟเวอร์ใดๆ ควรหมายถึงการสิ้นสุดเซสชันบนเซิร์ฟเวอร์ทั้งหมดในคราวเดียว

การรับส่งข้อมูลสูง 80% 1) โหลดถูกประมวลผลโดยเว็บเซิร์ฟเวอร์เดียวเท่านั้น 2) CPU โอเวอร์โหลด การประมวลผล PHP, เปิดใช้งานพรีคอมไพเลอร์แล้ว, ตรวจพบข้อผิดพลาดในการแบ่งส่วน งาน: scale" title="เว็บเซิร์ฟเวอร์ ฐานข้อมูล MySQL เว็บแอปพลิเคชัน โหลด CPU สูง >80% ทราฟฟิกสูง 1) โหลดถูกประมวลผลโดยเว็บเซิร์ฟเวอร์เดียวเท่านั้น 2) CPU ถูกประมวลผล โอเวอร์โหลดด้วยการประมวลผล PHP, เปิดใช้งานพรีคอมไพเลอร์, พบข้อผิดพลาดในการแบ่งส่วน งาน: สเกล" class="link_thumb"> 22 !}เว็บเซิร์ฟเวอร์ ฐานข้อมูล MySQL เว็บแอปพลิเคชัน โหลด CPU สูง >80% การรับส่งข้อมูลสูง 1) โหลดถูกประมวลผลโดยเว็บเซิร์ฟเวอร์เดียวเท่านั้น 2) CPU ถูกโอเวอร์โหลดด้วยการประมวลผล PHP, เปิดใช้งานพรีคอมไพเลอร์, ตรวจพบข้อผิดพลาดในการแบ่งส่วน งาน: ปรับขนาดตามโหลด เพิ่มขึ้น ปริมาณการใช้ข้อมูลสูง 80% 1) โหลดถูกประมวลผลโดยเว็บเซิร์ฟเวอร์เพียงเครื่องเดียว 2) CPU ถูกโอเวอร์โหลดด้วยการประมวลผล PHP, เปิดใช้งานพรีคอมไพเลอร์แล้ว, ตรวจพบข้อผิดพลาดในการแบ่งส่วน งาน: สเกล"> ปริมาณข้อมูลสูง 80% 1) โหลดถูกประมวลผลโดย เว็บเซิร์ฟเวอร์เดียวเท่านั้น 2) CPU โอเวอร์โหลดด้วยการประมวลผล PHP เปิดใช้งานพรีคอมไพเลอร์แล้ว ตรวจพบข้อผิดพลาดในการแบ่งส่วน งาน: การปรับขนาดเมื่อโหลดเพิ่มขึ้น"> การรับส่งข้อมูลสูง 80% 1) โหลดถูกประมวลผลโดยเว็บเซิร์ฟเวอร์เพียงแห่งเดียว 2) CPU มีโอเวอร์โหลดด้วยการประมวลผล PHP, เปิดใช้งานพรีคอมไพเลอร์แล้ว, ตรวจพบข้อผิดพลาดในการแบ่งส่วน งาน: scaling" title="(! LANG: เว็บเซิร์ฟเวอร์ ฐานข้อมูล MySQL เว็บแอปพลิเคชัน โหลด CPU สูง >80% ทราฟฟิกสูง 1) โหลดถูกประมวลผลโดยเพียงหนึ่งเดียว เว็บเซิร์ฟเวอร์ 2) CPU โอเวอร์โหลดด้วยการประมวลผล PHP, เปิดใช้งานพรีคอมไพเลอร์, ตรวจพบข้อผิดพลาดในการแบ่งส่วน งาน: สเกล"> title="เว็บเซิร์ฟเวอร์ ฐานข้อมูล MySQL เว็บแอปพลิเคชัน โหลด CPU สูง >80% การรับส่งข้อมูลสูง 1) โหลดถูกประมวลผลโดยเว็บเซิร์ฟเวอร์เดียวเท่านั้น 2) CPU ถูกโอเวอร์โหลดด้วยการประมวลผล PHP, เปิดใช้งานพรีคอมไพเลอร์, ตรวจพบข้อผิดพลาดในการแบ่งส่วน งาน: สเกล"> !}

ทำไมเราถึงเลือก csync2? เข้าถึงได้รวดเร็วไปยังไฟล์แอปพลิเคชันโดยใช้ ที่เก็บข้อมูลในเครื่อง. ความเร็วสูงงาน. การใช้ทรัพยากรต่ำ (CPU, การทำงานของดิสก์) ปัจจัยทั้งสองนี้ทำให้กระบวนการซิงโครไนซ์ทำงานได้บ่อยที่สุดเท่าที่จะเป็นไปได้ ดังนั้นข้อมูลบนเซิร์ฟเวอร์จึงเหมือนกันเกือบ "เรียลไทม์" ติดตั้งง่ายสำหรับการแลกเปลี่ยนข้อมูลระหว่างเซิร์ฟเวอร์จำนวนเท่าใดก็ได้ ความสามารถในการซิงโครไนซ์การลบไฟล์ การสื่อสารระหว่างโฮสต์กับโฮสต์ (SSL) ที่ปลอดภัย

เว็บเซิร์ฟเวอร์ ฐานข้อมูล MySQL MASTER "1C-Bitrix: เว็บคลัสเตอร์" ฐานข้อมูล MySQL SLAVE 1 ฐานข้อมูล MySQL SLAVE N ออนไลน์ การสำรองข้อมูลดิสก์ การสำรองข้อมูลเชิงตรรกะ/กายภาพแบบองค์รวมของ MySQL โดยไม่ทำให้ระบบหลักช้าลง ฐานข้อมูล MySQL MASTER ตัวเลือก DRBD – ออนไลน์ การสำรองข้อมูลบนดิสก์ด้วยการจัดฐานข้อมูล การสำรองข้อมูล- มายเอสคิวแอล

เว็บเซิร์ฟเวอร์ "1C-Bitrix: Web Cluster" /var/www LVM /var/www – snapshot 1 /var/www – snapshot 2 /var/www – snapshot 3 รวดเร็วและสำรองข้อมูลเสร็จสมบูรณ์ ระดับลินุกซ์การสำรองข้อมูลแบบรวมที่รวดเร็ว องค์รวม เพิ่มขึ้น และรวมโดยอัตโนมัติโดยใช้เครื่องมือโฮสติ้ง การจัดระเบียบไฟล์สำรอง

"1C-Bitrix: เว็บคลัสเตอร์", DC ในมอสโก DB เว็บโหนด "1C-Bitrix: เว็บคลัสเตอร์", DC ในนิวยอร์ก "1C-Bitrix: เว็บคลัสเตอร์", DC ในโนโวซีบีร์สค์แบบวงกลม, อะซิงโครนัส, การจำลองแบบมาสเตอร์ - มาสเตอร์เพื่อให้แน่ใจว่า การทำงานของคลัสเตอร์เว็บที่กระจายตามภูมิศาสตร์ 1C-Bitrix Cache DB Web node Cache DB Web node Cache เรากำลังดำเนินการ...

"1C-Bitrix: เว็บคลัสเตอร์", DC ในมอสโก DB เว็บโหนด "1C-Bitrix: เว็บคลัสเตอร์", DC ในนิวยอร์ก "1C-Bitrix: เว็บคลัสเตอร์", DC ในโนโวซีบีร์สค์แบบวงกลม, อะซิงโครนัส, การจำลองแบบมาสเตอร์ - มาสเตอร์เพื่อให้แน่ใจว่า การทำงานของคลัสเตอร์เว็บที่มีการกระจายทางภูมิศาสตร์ 1C-Bitrix DB Cache Web node DB Cache Web node DB Cache Web node DB Cache Web node DB Cache Web node DB Cache Web node DB Cache Web node Cache DB Web node Cache เรากำลังดำเนินการ...

ความเสถียรของระบบเมื่อปิดโหนดคลัสเตอร์ของเว็บ เมื่อปิดโหนดคลัสเตอร์ ระบบจะไม่ขัดจังหวะการบริการลูกค้า คิวเพิ่มขึ้น (เวลาที่ใช้ในการส่งเพจไปยังไคลเอนต์เพิ่มขึ้น) แต่โดยรวมแล้วระบบมีความสมดุลของโหลด การเพิ่มโหนดคลัสเตอร์เว็บกลับจะช่วยเพิ่มประสิทธิภาพของระบบตามสัดส่วน ทดสอบโหลด– การปิดระบบโหนดคลัสเตอร์ตัวใดตัวหนึ่ง