เครื่องคำนวณเซิร์ฟเวอร์เทอร์มินัล: วิธีการกำหนดขนาดทรัพยากร

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

เซิร์ฟเวอร์เทอร์มินัลคำนวณอะไรได้บ้าง?

เครื่องคำนวณเซิร์ฟเวอร์เทอร์มินัลที่มีประโยชน์ควรประเมินมากกว่า "ผู้ใช้ต่อเซิร์ฟเวอร์" ในฐานะผู้ดูแลระบบ มันควรช่วยให้คุณวางแผนสำหรับ CPU, RAM, ประสิทธิภาพการจัดเก็บ, การจัดเก็บโปรไฟล์ และขอบเขตความจุภายใต้การใช้งานพร้อมกันที่เป็นจริง คำแนะนำของ Microsoft สำหรับโฮสต์เซสชัน Remote Desktop กำหนดขนาดตามประเภทของภาระงานและจำนวนผู้ใช้ที่แนะนำต่อ vCPU ไม่ใช่ตามขีดจำกัดการเชื่อมต่อแบบทั่วไปที่ใช้ได้กับทุกคน

ทำไมจำนวนผู้ใช้เพียงอย่างเดียวจึงไม่เพียงพอในการคำนวณทรัพยากรบนเซิร์ฟเวอร์เทอร์มินัล?

การใช้งานเซสชัน

โปรดทราบว่า สองสภาพแวดล้อมที่มีจำนวนผู้ใช้เท่ากันสามารถสร้างผลลัพธ์ที่แตกต่างกันมาก เรา assume ว่าคุณรู้แล้วว่ามีผู้ใช้กี่คนที่จะเข้าถึงโครงสร้างพื้นฐานของคุณ ดังนั้นการมี พิจารณาใบอนุญาตและ CALs การทำงานจริงสามารถเริ่มต้นได้

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

ความแตกต่างมีความสำคัญเพราะ “30 ผู้ใช้” ไม่ใช่ตัวเลขความจุด้วยตัวมันเอง มันมีความหมายก็ต่อเมื่อคุณกำหนด ผู้ใช้เหล่านั้นทำอะไรและใช้สิ่งใด ในช่วงเวลาที่มีความต้องการสูง

การใช้งานเซิร์ฟเวอร์

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

1 เซิร์ฟเวอร์สำหรับโบรกเกอร์, เว็บ และการอนุญาต
1 หรือมากกว่าของเซิร์ฟเวอร์สำหรับโฮสต์เซสชัน
1 RD Gateway บนเซิร์ฟเวอร์ของตนเองสำหรับการเข้าถึงภายนอก.

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

การวางแผนทรัพยากรมีปัจจัยสี่ประการใดบ้าง?

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

ดังนั้นคุณต้องรวมยอด:

ผู้ใช้ที่ใช้งานพร้อมกัน

เรายังต้องรวมหมายเลขที่สำคัญนี้ไว้ เนื่องจากจำนวนเซสชันที่ทำงานพร้อมกันจะส่งผลต่อประสิทธิภาพของเซิร์ฟเวอร์อย่างแน่นอน โปรดทราบว่าจำนวนที่ทำงานพร้อมกันอาจแยกจากจำนวนรวมได้

คลาสภาระงานต่อกลุ่มผู้ใช้

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

ประเภทแอปพลิเคชันและเซสชัน

มันยังเป็นประโยชน์อย่างมากในการระบุแอปพลิเคชันเฉพาะ เนื่องจากผู้ใช้บางคนจะใช้ทรัพยากรจำนวนมากตามแอปพลิเคชันที่พวกเขาใช้งาน

ยอดสูงสุด, การเติบโตและขอบการล้มเหลว

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

คุณคำนวณทรัพยากรบนเซิร์ฟเวอร์เทอร์มินัลได้อย่างไร?

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

ขั้นตอนที่ 1: นับผู้ใช้ที่ใช้งานพร้อมกัน ไม่ใช่ผู้ใช้ทั้งหมด

เริ่มต้นด้วยจำนวนผู้ใช้ที่ใช้งานพร้อมกัน นี่คือจำนวนที่ส่งผลต่อการโหลดของเซิร์ฟเวอร์ ธุรกิจที่มีผู้ใช้ที่ตั้งชื่อไว้ 50 คนอาจมีผู้เชื่อมต่อพร้อมกันเพียง 18 ถึง 25 คนในช่วงเวลาที่มีการใช้งานสูง เมื่อกำหนดขนาดของโฮสต์เซสชัน จำนวนเซสชันพร้อมกันมีประโยชน์มากกว่าจำนวนผู้ใช้ทั้งหมด

ก่อนที่จะทดสอบความสามารถที่ยั่งยืนในโลกจริงภายใต้ภาระงาน การวางแผนจำเป็นต้องท้าทายการประมาณการ

ขั้นตอนที่ 2: จำแนกภาระงานเป็นเบา กลาง หรือหนัก

ถัดไป จัดกลุ่มผู้ใช้ตามภาระงานของพวกเขา Microsoft’s คำแนะนำสำหรับโฮสต์เซสชันปัจจุบัน แนะนำช่วงความหนาแน่นพื้นฐานสำหรับสภาพแวดล้อมหลายเซสชันและ HP และแหล่งข้อมูลอื่น ๆ เห็นด้วย:

สูงสุด 6 ผู้ใช้ที่ใช้งานเบา ๆ ต่อ vCPU,
4 ผู้ใช้ระดับกลางต่อ vCPU และ
2 ผู้ใช้หนักต่อ vCPU,

โดยมีตัวอย่าง VM ขั้นต่ำที่มี 8 vCPU, 16 GB RAM, 32 GB storage ในแต่ละกลุ่มภาระงาน คำแนะนำยังรวมถึงการรักษาขนาด VM หลายเซสชันให้อยู่ระหว่าง 4 ถึง 24 vCPUs เพื่อผลตอบแทนด้านความจุที่ดีกว่า

แผนที่ภาระงานที่ง่ายสำหรับการวางแผน SMB จะช่วยในการจัดเรียง:

แสง: แอปพลิเคชันธุรกิจหนึ่ง, การใช้เบราว์เซอร์ที่จำกัด, เซสชันสั้น
ขนาดกลาง: แอปพลิเคชันสำนักงาน, แท็บเบราว์เซอร์, เครื่องมือ PDF, การทำงานหลายอย่างในระดับปานกลาง
หนัก: ERP, ไฟล์ Excel ขนาดใหญ่, การใช้เบราว์เซอร์อย่างต่อเนื่อง, การพิมพ์, แอปหลายตัวเปิดตลอดทั้งวัน

นี่คือแถบการวางแผนพื้นฐาน ไม่ใช่การรับประกัน จุดประสงค์คือการเลือกจุดเริ่มต้นที่มีพื้นฐานจากพฤติกรรมของภาระงาน

ขั้นตอนที่ 3: ประเมินความจุ CPU

เมื่อผู้ใช้ถูกจัดกลุ่มแล้ว ให้ประมาณการ CPU โดยใช้วิธีการผู้ใช้ต่อ vCPU ตัวอย่างเช่น หากผู้ใช้ 24 คนที่ทำงานพร้อมกันส่วนใหญ่เป็นผู้ใช้ระดับกลาง มาตรฐานของ Microsoft ที่ประมาณ 4 ผู้ใช้ต่อ vCPU แนะนำให้เริ่มต้นที่ประมาณ 6 vCPUs จากนั้นจึงปัดขึ้นไปยังขนาดโฮสต์ที่เหมาะสมพร้อมพื้นที่สำหรับการเพิ่มขึ้น หากคุณต้องการให้ความสามารถในการเพิ่มขึ้นที่ดีกว่าในช่วงที่มีความต้องการ CPU ชั่วคราว ให้วางแผนอัตราส่วนผู้ใช้ต่อคอร์ที่ต่ำกว่าที่คุณอาจทำได้ในกรณีอื่น

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

ขั้นตอนที่ 4: ประเมินความต้องการ RAM

RAM ควรครอบคลุมความต้องการของระบบปฏิบัติการ บริการหลัก ภาระงานเซสชัน และการใช้หน่วยความจำของแอปพลิเคชันต่อผู้ใช้ ตามที่ได้อธิบายไว้ข้างต้น มาตรฐานหลายเซสชันของ Microsoft ในปัจจุบันได้จับคู่ตัวอย่างภาระงานที่เบา ปานกลาง และหนักกับ RAM ขั้นต่ำ 16 GB สำหรับจุดเริ่มต้น 8 vCPU แม้ว่านี่จะเป็นเพียงมาตรฐาน แต่ก็ยังให้จุดเริ่มต้นที่จับต้องได้สำหรับการประมาณการ

วิธีการที่ใช้ได้จริงในธุรกิจขนาดเล็กหรือขนาดกลางคือ:

สำรองหน่วยความจำสำหรับระบบปฏิบัติการและบริการแพลตฟอร์ม,
ประมาณการหน่วยความจำต่อเซสชันตามประเภทผู้ใช้,
คูณด้วยเซสชันพร้อมกัน,
จากนั้นเพิ่มขอบเขตความปลอดภัย。

PeteNetLive ให้บริการ กฎเกณฑ์ที่กว้างขวางโดยเจตนา ของ 2 ถึง 8 GB ต่อผู้ใช้สำหรับการวางแผน RAM ของ RD Session Host ซึ่งมีประโยชน์เป็นการเตือนเกี่ยวกับการประเมินเซสชันที่หนักเกินไป แม้ว่าหมายเลขที่แน่นอนจะต้องได้รับการปรับปรุงในการทดสอบ

ขั้นตอนที่ 5: ตรวจสอบการจัดเก็บและค่าใช้จ่ายโปรไฟล์

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

การจัดเก็บโปรไฟล์
การจัดเก็บ OS
บันทึก: เพื่อความปลอดภัยและวัตถุประสงค์อื่น ๆ

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

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

ขั้นตอนที่ 6: เพิ่มพื้นที่สำหรับจุดสูงสุด การเติบโต และการเปลี่ยนผ่าน

ไม่มีเครื่องคำนวณเซิร์ฟเวอร์เทอร์มินัลใดควรสิ้นสุดด้วยหมายเลข “พอเพียง” เพียงพอ เพิ่มพื้นที่ว่างสำหรับ:

การลงชื่อเข้าใช้ในช่วงเช้าสูงขึ้น
การแพตช์และการสแกน AV
ยอดการรายงานรายเดือนสูงสุด
การเติบโตของผู้ใช้ที่คาดหวัง
ความล้มเหลวของโฮสต์ในรูปแบบหลายเซิร์ฟเวอร์

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

วิธีการคำนวณเซิร์ฟเวอร์เทอร์มินัลที่ง่ายสำหรับ SMBs และ MSPs

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

สูตรการวางแผนอย่างรวดเร็ว

ใช้ลำดับนี้:

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

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

ตัวอย่างที่ 1: ผู้ใช้สำนักงาน 15 คน

สมมติว่าผู้ใช้ 15 คนเข้าถึงแอปธุรกิจที่เผยแพร่พร้อมกับการใช้งานเบราว์เซอร์เบา ๆ

การใช้เกณฑ์พื้นฐานที่แนะนำเบา ๆ การประมาณการ CPU ดิบอยู่ที่ประมาณ 3 vCPUs ในทางปฏิบัติ นั่นแน่นเกินไปสำหรับความสามารถในการระเบิด ดังนั้นผู้วางแผนจะเลือกใช้โปรไฟล์โฮสต์ที่เหมาะสมมากกว่าการสร้างให้ถึงขอบ คุณจะพบว่าคำแนะนำสนับสนุนช่วงขนาด 4 ถึง 24 vCPU ที่กว้างขึ้น โดยมี 8 vCPU และ RAM 16 GB เป็นโปรไฟล์พื้นฐานมาตรฐานสำหรับงานหลายเซสชัน

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

ตัวอย่าง 2: 30 ผู้ใช้สำนักงานและ ERP แบบผสม

สมมติว่า:

18 ผู้ใช้ระดับกลาง
12 ผู้ใช้ที่มีน้ำหนักมาก

ทางลัดในการวางแผนจะพิจารณากลุ่มขนาดกลางที่ประมาณ 4 ผู้ใช้ต่อ vCPU และกลุ่มหนักที่ประมาณ 2 ผู้ใช้ต่อ vCPU ซึ่งหมายความว่าประมาณ 4.5 vCPUs สำหรับกลุ่มขนาดกลางและ 6 vCPUs สำหรับกลุ่มหนัก ก่อนที่จะมีค่าใช้จ่ายเพิ่มเติมและพื้นที่ว่าง ในทางปฏิบัติแล้ว นั่นชี้ให้เห็นว่าไม่ควรใช้โฮสต์ขนาดเล็กเพียงตัวเดียว แต่ควรใช้โฮสต์ขนาดใหญ่ที่มีมาร์จิ้นหรือแบ่งเป็นหลายโฮสต์เซสชัน

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

ตัวอย่างที่ 3: เมื่อใดควรแยกผู้ใช้ไปยังโฮสต์หลายตัว

เมื่อการคำนวณผลิตโฮสต์ที่หนาแน่นซึ่งมีความสามารถในการระเบิดที่จำกัด คำตอบที่ดีกว่าอาจเป็นด้านสถาปัตยกรรมมากกว่าการปรับขนาดแนวตั้ง โฮสต์เซสชันสามารถตั้งค่าให้ทำงานหนัก ในขณะที่บทบาทเช่น RD Connection Broker, Gateway และ Licensing สามารถกำหนดโปรไฟล์ทรัพยากรที่แตกต่างกัน การแบ่งภาระผู้ใช้ระหว่างโฮสต์หลายตัวมีแนวโน้มที่จะปรับปรุงความยืดหยุ่น ความยืดหยุ่นในการบำรุงรักษา และการวางแผนการเปลี่ยนผ่าน

สำหรับ MSPs นี่มักจะเป็นจุดเปลี่ยนที่เครื่องคำนวณเซิร์ฟเวอร์เทอร์มินัลกลายเป็นการสนทนาเกี่ยวกับขนาดฟาร์มแทนที่จะเป็นการสนทนาเกี่ยวกับเซิร์ฟเวอร์เดียว

ข้อผิดพลาดในการกำหนดขนาดทั่วไปที่มักทำให้ประสิทธิภาพของเซิร์ฟเวอร์เทอร์มินัลลดลงคืออะไร?

ข้อผิดพลาดในการกำหนดขนาดมักไม่ได้เกิดจากคณิตศาสตร์เพียงอย่างเดียว แต่เกิดจากการตั้งสมมติฐานที่ไม่ถูกต้อง

การสับสนระหว่างการอนุญาตใช้งานกับความสามารถในการทำงาน

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

การละเลยเซสชันที่ใช้เบราว์เซอร์หนักและเซสชันที่ใช้การพิมพ์หนัก

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

การกำหนดขนาดเฉพาะสำหรับโหลดเฉลี่ย

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

ลืมส่วนที่เหลือของ RDS stack

โฮสต์เซสชันเป็นผู้บริโภคทรัพยากรหลัก แต่ไม่ใช่บทบาทเดียวในสภาพแวดล้อม การแบ่งบทบาทของ PeteNetLive เป็นการเตือนที่มีประโยชน์ให้พิจารณา Connection Broker, Gateway, Web Access และ Licensing แยกกันเมื่อการติดตั้งขยายเกินกว่าการตั้งค่าโฮสต์เดียวขนาดเล็ก

ทำไมการตรวจสอบจึงควรตรวจสอบการประมาณขนาดของคุณ?

เครื่องคำนวณเซิร์ฟเวอร์เทอร์มินัลให้แนวทางการวางแผนแก่คุณ มันไม่ได้ให้หลักฐานแก่คุณ สำหรับหลักฐาน คุณต้องติดตามการใช้งาน

จากพื้นฐานสู่การพิสูจน์: การตรวจสอบเป็นสิ่งจำเป็น

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

TSplus Server Monitoring ทำให้เกิดความแตกต่างที่ไหน?

TSplus การตรวจสอบเซิร์ฟเวอร์ พอดี หลังจากการประเมินขนาดถูกนำไปใช้ จะช่วยตรวจสอบว่าการใช้ CPU เต็มขีด ความกดดันของหน่วยความจำ ข้อจำกัดของการจัดเก็บ หรือการเพิ่มขึ้นของการใช้งานตรงตามสมมติฐานที่ใช้ในการวางแผนหรือไม่ ซึ่งมีประโยชน์โดยเฉพาะสำหรับผู้ดูแลระบบ IT ของ SMB และ MSP ที่ต้องการหลักฐานก่อนที่จะปรับขนาดโฮสต์ แจกจ่ายผู้ใช้ใหม่ หรือเพิ่มเซิร์ฟเวอร์อีกเครื่องหนึ่ง

นอกเหนือจากการรู้วิธีการจัดสรรทรัพยากร คุณจะรู้ได้อย่างไรว่าการคำนวณนั้นถูกต้องหรือไม่ นอกจากการตรวจสอบระบบ? Server Monitoring ให้การตรวจสอบแบบเรียลไทม์และการแจ้งเตือนเพื่อให้คุณได้รับข้อมูลเมื่อใดก็ตามที่ตัวชี้วัดถึงเกณฑ์ที่คุณตั้งไว้ .

ซอฟต์แวร์ TSplus สำหรับการส่งมอบแอปพลิเคชันและเดสก์ท็อปอย่างปลอดภัยและต่อเนื่อง

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

สรุป

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

ในฐานะผู้ดูแลระบบ ผู้ดูแล IT ของ SMB หรือ MSP นี่จะให้การประเมินเบื้องต้นที่เป็นประโยชน์แก่คุณ จากนั้น วินัยที่แท้จริงคือการตรวจสอบ วางแผนอย่างรอบคอบ ติดตั้งอย่างระมัดระวัง และจากนั้นใช้ข้อมูลการตรวจสอบเพื่อยืนยันว่าฮอสต์หรือ ฟาร์มโฮสต์ สามารถรักษาประสบการณ์ผู้ใช้ที่คุณตั้งใจไว้

วิธีคำนวณทรัพยากรบนเซิร์ฟเวอร์เทอร์มินัล: วิธีการกำหนดขนาดที่ใช้งานได้