วันนี้ 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และ โหลดบาลานซ์ระหว่างเซิร์ฟเวอร์
• กระจาย แคชข้อมูล(เมมแคช)
• ความต่อเนื่องของเซสชันระหว่างเว็บเซิร์ฟเวอร์ (จัดเก็บเซสชันในฐานข้อมูล)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 เรากำลังดำเนินการ...

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