วิธีที่ดีที่สุดในการขยายแอปพลิเคชัน IIS / SQL Server

เรามีแอพพลิเคชั่นที่เราพัฒนาใน ASP และ SQL Server เราใช้ Rackspace เพื่อโฮสต์ "ลูกค้า" ของเราแต่ละคนมีไซต์ IIS และฐานข้อมูล SQL ของตนเอง ลูกค้าแต่ละรายอาจมีผู้ใช้หลายสิบหรือหลายร้อยคนที่กดปุ่มแอปพลิเคชัน

ตอนนี้เรามีลูกค้าหลายร้อยคน สิ่งที่เราทำมาจนถึงตอนนี้คือการเพิ่มเซิร์ฟเวอร์อีกคู่หนึ่ง (IIS หนึ่งตัว, หนึ่ง SQL) เมื่อเราต้องการเหตุผลด้านประสิทธิภาพ ตอนนี้เรามีเซิร์ฟเวอร์มากถึงสี่คู่

เรากำลังเพิ่มลูกค้าใหม่อย่างต่อเนื่องและเรากำลังค้นหาวิธีอื่น ๆ ในการขยายขนาดโดยไม่ต้องเพิ่มเซิร์ฟเวอร์คู่อื่น ๆ

วิธีหนึ่งที่เรากำลังพิจารณาคือการมีเว็บฟาร์มสำหรับฝั่ง IIS และคลัสเตอร์ SQL Server และ SAN สำหรับด้านฐานข้อมูล

นี่เป็นวิธีที่ดีหรือไม่? ขณะนี้เรามีลูกค้า 400 รายโดยแต่ละไซต์มี IIS และฐานข้อมูล SQL ของตัวเอง เกิดอะไรขึ้นถ้าเราเติบโตถึง 1,000? 5,000? SQL คลัสเตอร์เดียวสามารถจัดการฐานข้อมูลหลายพันฐานข้อมูลได้หรือไม่

แต่ละฐานข้อมูลมีหลายร้อยตาราง ตารางหลักสำหรับลูกค้ารายใหญ่ของเราอาจมีหลายแสนรายการ

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

คลัสเตอร์ SQL Server ไม่ใช่โซลูชันที่สามารถปรับขยายได้ แต่เป็นโซลูชันที่มีความพร้อมใช้งานสูงอย่างเคร่งครัด ในคลัสเตอร์ SQL Server มีเพียงโหนดเดียวเท่านั้นที่ใช้งานและจัดการโหลดโหนดอื่น ๆ ทั้งหมดเป็นเพียงการรอคอยแบบพาสซีฟรอในกรณีที่โหนดที่ใช้งานอยู่มีฮาร์ดแวร์ที่ล้มเหลว ด้วยเหตุนี้จึงทำให้คลัสเตอร์ SQL Server ของคุณได้รับประสิทธิภาพของอินสแตนซ์ของ SQL Server เดียว บางครั้งคุณอาจพบว่ามีการอ้างอิงถึงการปรับใช้ 'Active-Active' แต่นั่นไม่ใช่คลัสเตอร์ SQL Server ที่เรียกว่า 'Active-Active' เป็นสองกลุ่มที่แยกกันซึ่งใช้โหนดของกันและกันในบทบาทย้อนกลับ (หนึ่งคลัสเตอร์ในแอ็คทีฟบนโหนด A และ passive บน B ส่วนอีกอันคือ active B และ passive บน A)

หากแอปพลิเคชันของคุณได้รับการแบ่งพาร์ติชั่นแล้วและลูกค้าแต่ละรายมีฐานข้อมูลแยกต่างหาก ปัญหาของการบริหารและการบำรุงรักษาสามารถแก้ไขได้เมื่อคุณจัดการเซิร์ฟเวอร์ 4 เครื่อง (เช่นตอนนี้) โดยอัตโนมัติคุณสามารถจัดการเซิร์ฟเวอร์ 1000 เครื่องโดยอัตโนมัติ ดังนั้นปัญหาของการกำหนดเวอร์ชันการปรับใช้และการจัดสรรบัญชี

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

อัปเดตหลังจากที่คุณแก้ไข OP พร้อมคำอธิบายเกี่ยวกับข้อกังวลที่เกี่ยวข้องกับการไต่ระดับ

การเพิ่มขนาดและการจัดกลุ่มที่แท้จริงนำเสนอโซลูชันความพร้อมใช้งานสูง โดยทั่วไปจะมีสองโซลูชัน HA สำหรับ SQL Server: การทำคลัสเตอร์และการทำมิเรอร์ฐานข้อมูล เมื่อคุณวางแผนสำหรับฐานข้อมูลหลายพันฐานข้อมูลกฎนี้ค่อนข้างสะท้อนออกมา สิ่งที่คุณต้องระลึกไว้เสมอคือคลัสเตอร์ SQL Server ได้รับการสนับสนุนในรายการที่ จำกัด ของการรวมกันของฮาร์ดแวร์ :

กลุ่มเซิร์ฟเวอร์ Microsoft ได้รับการสนับสนุนเฉพาะในโซลูชันคลัสเตอร์ที่ระบุไว้ในแค็ตตาล็อกเซิร์ฟเวอร์ Windows ภายใต้โซลูชันคลัสเตอร์ หากต้องการดูแคตตาล็อกเซิร์ฟเวอร์ Windows ให้เยี่ยมชมเว็บไซต์ของ Microsoft ต่อไปนี้: http://www.windowsservercatalog.com/

ไม่ได้หมายความว่าคุณจะไม่สามารถเรียกใช้คลัสเตอร์ในคู่ฮาร์ดแวร์ / กลุ่มใด ๆ ที่มี SCSI บัสได้ หมายความว่าคุณจะไม่สามารถขอการสนับสนุนจาก Microsoft CSS หากคุณมีปัญหาเกี่ยวกับฮาร์ดแวร์ที่ไม่ได้รับการอนุมัติ

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

สำหรับคำถามของคุณเกี่ยวกับจำนวนฐานข้อมูลที่สามารถเรียกใช้คลัสเตอร์ได้ในที่สุดคลัสเตอร์จะมีเพียงหนึ่งอินสแตนซ์ที่ใช้งานได้ตลอดเวลาดังนั้นข้อ จำกัด ของอินสแตนซ์เดียวที่ใช้กับคลัสเตอร์ก็เช่นกัน มีฐานข้อมูลหนึ่งพันที่แนบมาไม่ใช่เรื่องใหญ่คำถามจริงคือการโหลดจำนวนผู้ใช้ที่จะเรียกใช้แบบสอบถามพร้อมกัน ในการรับพื้นที่ ballpark ของตัวเลขให้พิจารณาว่าเกณฑ์มาตรฐาน TPC-C ที่เผยแพร่สำหรับ SQL Server นั้นสำหรับธุรกรรม 1.2 ล้านต่อนาทีใน 64 บิต Superdome ซึ่งหมายถึงธุรกรรม 16k ต่อวินาทีโดยประมาณ คุณคาดหวังเกี่ยวกับการเชื่อมต่อ 5k ลูกค้าที่ช่วยให้คุณขอบของ 3 คำสั่งต่อลูกค้าต่อวินาทีและไปถึงว่าคุณต้องมีฮาร์ดแวร์ beeffy สวยและล้ำแอพลิเคชัน tunned ดี

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

ในแง่ของกลยุทธ์การปรับขนาดจริงฉันคิดว่าการตั้งค่าที่เป็นไปได้สำหรับคุณอาจมีลักษณะดังต่อไปนี้

1) ไฟล์เว็บของลูกค้าทั้งหมดอยู่ในเว็บเซิร์ฟเวอร์ทั้งหมด

2) เว็บไซต์ลูกค้าทั้งหมดกำหนดค่าใน IIS บนเซิร์ฟเวอร์ทั้งหมด

3) การเปลี่ยนแปลงของไฟล์เว็บลูกค้าใด ๆ จะซิงค์กับเว็บเซิร์ฟเวอร์ทั้งหมด

4) การกำหนดค่าเว็บดังต่อไปนี้

          - - - - - - - - - - - - - -
         |      Load Balancer       |
          - - - - - - - - - - - - - -
                        |
                        |
 - - - -    - - - -     - - - -     - - - -
| web |   | web |   | web |   | web |
 - - - -    - - - -     - - - -     - - - -
    |            |             |            |
          - - - - - - - - - - - - - -
         |      SQL Cluster          |
          - - - - - - - - - - - - - -
                      |
                      |
          - - - - - - - - - - - - - -
         |    Warm SQL Cluster    |
          - - - - - - - - - - - - - -

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

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

นอกจากนี้เรากำลังปล่อยให้เซิร์ฟเวอร์ฐานข้อมูลทำสิ่งที่ดีที่สุดและเมื่อพวกเขาเริ่มจมลงเราจะเพิ่มเซิร์ฟเวอร์ \ คลัสเตอร์ใหม่ลงในส่วนผสมเพื่อสร้างสมดุลให้กับงาน SQL Server อันอบอุ่นมอบความซ้ำซ้อนระดับหนึ่งให้คุณแม้ว่าอาจมีความขัดแย้งกับฉันที่นี่ว่าจะต้องใช้จริงหรือไม่

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

อย่างไรก็ตาม .... นั่นคือ 2 เซ็นต์ของฉัน

คุณอาจต้องการพิจารณาโซลูชันคลาวด์เช่น EC2 ของ Amazon Web Services และฐานข้อมูลเสริมและบริการจัดเก็บข้อมูล ง่ายต่อการปรับขนาดและตั้งโปรแกรมได้อย่างสมบูรณ์ คุณสามารถสร้างแดชบอร์ดที่กำหนดเองเพื่อจัดการเซิร์ฟเวอร์ทั้งหมดของคุณและขยายขนาดตามที่คุณต้องการ คุณจ่ายเฉพาะสิ่งที่คุณใช้และรองรับแพลตฟอร์ม Windows และ Linux รวมถึง IIS คุณสามารถสร้างภาพที่กำหนดเองของคุณเองได้หากคุณต้องการขยายไปยังเซิร์ฟเวอร์หลายเครื่องหรือให้ความซ้ำซ้อนทางภูมิศาสตร์ด้วยการโฮสต์เซิร์ฟเวอร์บนชายฝั่งตะวันออกและตะวันตกหรือแม้แต่ยุโรป Rackspace มีวิธีแก้ไขปัญหาที่คล้ายกัน แต่ฉันไม่แน่ใจว่าพวกเขาเปิดตัวการสนับสนุน Windows หรือไม่ - อาจมี ฉันลองทั้งสองและพบว่า Amazon มีความยืดหยุ่นและครอบคลุมมากกว่า แต่เนื่องจากคุณอยู่ใน Rackspace อยู่แล้วมันอาจเข้าท่ามากกว่านี้ โชคดี!