Cara Mengira Sumber pada Pelayan Terminal: Kaedah Penentuan Saiz yang Praktikal

Pengira pelayan terminal jarang merupakan pengira literal. Dalam kebanyakan persekitaran SMB dan MSP, ia adalah kaedah perancangan yang digunakan untuk menganggarkan berapa banyak CPU, RAM, penyimpanan dan ruang tambahan yang diperlukan oleh pelayan terminal sebelum pengguna mula mengadu. Soalan sebenar di sebalik kata kunci adalah praktikal: bagaimana anda mengira sumber pada pelayan terminal dengan cukup baik untuk melaksanakan dengan keyakinan, mengelakkan perbelanjaan berlebihan dan mengurangkan risiko penyempitan prestasi ?

Apa yang sepatutnya dikira oleh kalkulator pelayan terminal?

Pengira pelayan terminal yang berguna harus menganggarkan lebih daripada "pengguna per pelayan." Sebagai pentadbir, ia harus membantu anda merancang untuk CPU, RAM, prestasi storan, storan profil dan margin kapasiti di bawah penggunaan serentak yang realistik. Panduan Microsoft untuk hos sesi Remote Desktop membingkai saiz berdasarkan jenis beban kerja dan pengguna yang disyorkan per vCPU, bukan berdasarkan had sambungan generik yang satu saiz untuk semua.

Mengapa jumlah pengguna sahaja tidak mencukupi untuk mengira sumber pada pelayan terminal?

Penggunaan sesi

Ambil perhatian, dua persekitaran dengan jumlah pengguna yang sama boleh menghasilkan keputusan yang sangat berbeza. Kami menganggap anda sudah tahu berapa ramai pengguna yang akan mengakses infrastruktur anda, jadi mempunyai dipertimbangkan pelesenan dan CALs kerja praktikal boleh dimulakan.

Bayangkan bagaimana lima belas pengguna yang membuka satu aplikasi perniagaan mungkin memberikan beban sederhana pada hos. Sementara itu, lima belas pengguna yang menjalankan desktop jauh penuh dengan pelayar, aplikasi Office, alat PDF, pencetakan dan penyegerakan latar belakang boleh mencipta jejak yang jauh lebih berat. Model saiz mencerminkan perbezaan itu dengan memisahkan beban kerja sesi pelbagai yang ringan, sederhana dan berat.

Perbezaan ini penting kerana "30 pengguna" bukanlah angka kapasiti dengan sendirinya. Ia hanya bermakna setelah anda mendefinisikannya. apa yang pengguna tersebut lakukan dan gunakan semasa waktu puncak.

Penggunaan pelayan

Ingat juga satu perbezaan penting yang sangat bermakna: untuk makmal atau pejabat kecil, anda mungkin merancang satu pelayan, kerana ia akan menjalankan sesi pengguna serentak yang lebih sedikit, manakala untuk pengeluaran, anda mungkin merancang sebuah ladang. Memang, peranan yang berasingan diperlukan untuk meningkatkan prestasi, memudahkan penyelesaian masalah dan mengunci keselamatan, jadi pembahagian yang biasa adalah:

• 1 pelayan untuk Broker, Web dan Pelesenan
• 1 atau lebih pelayan untuk Host Sesi
• 1 Gateway RD pada pelayannya sendiri untuk akses luar.

Untuk melangkah lebih jauh, anda juga akan mendapati bahawa jenis pelayan, memori, dan lain-lain, akan memainkan peranan dan anda mungkin ingin sertakan SSD dalam pemasangan yang lebih besar Sebagai contoh. Namun, ini hanya sebutan untuk membuat anda sedar tentang kemungkinan.

Empat input manakah yang membentuk perancangan sumber?

Seterusnya, lebih boleh dipercayai daripada melompat terus ke nombor perkakasan, berikut adalah empat input untuk dikumpulkan sebelum mula mengira. Kerja hulu ini mengelakkan pertindihan dengan soalan pelesenan tentang siapa yang boleh menyambung dan di bawah peraturan Microsoft yang mana. Kebimbangan utama di sini adalah berapa banyak sumber yang diperlukan oleh hos sesi untuk kekal responsif. Artikel kami sebelum ini membincangkan pelesenan dan kapasiti pelayan supaya kita dapat mengembangkan di sini praktikaliti mengira segala-galanya secara metodik untuk merancang dengan betul.

Oleh itu, anda perlu menjumlahkan:

Pengguna aktif serentak

Kami masih perlu memasukkan nombor penting ini kerana bilangan sesi yang dijalankan secara serentak pasti akan mempengaruhi prestasi pelayan. Perhatikan bahawa jumlah serentak boleh bebas daripada jumlah keseluruhan.

Kelas beban kerja mengikut kumpulan pengguna

Menilai berapa banyak seorang pengguna atau sekumpulan pengguna akan menggunakan sumber adalah pemeriksaan realiti yang pertama. Kumpulan atau individu tertentu pasti akan menggunakan lebih banyak daripada tugas yang mereka laksanakan. Oleh itu, pengguna berat perlu dikenalpasti.

Jenis aplikasi dan sesi

Ia juga sangat berguna untuk mengenal pasti aplikasi tertentu, kerana pengguna tertentu akan memonopoli sejumlah besar sumber bergantung kepada aplikasi yang mereka jalankan.

Puncak, margin pertumbuhan dan fail-over

Senaraikan input ini dengan mengambil kira penggunaan maksimum, meninggalkan ruang untuk pertumbuhan jangka pendek yang dijangkakan dan membina margin penampan untuk kegagalan.

Bagaimana Anda Mengira Sumber pada Pelayan Terminal?

Berikut adalah kaedah pengiraan praktikal yang kami harap akan berguna dalam pentadbiran SMB serta konteks lain. Ia bertujuan untuk sekurang-kurangnya memudahkan perancangan dan struktur persediaan. Kemudian, ia seharusnya dapat dipertingkatkan supaya anda boleh bergantung padanya semasa tempoh percubaan dan seterusnya.

Langkah 1: Kira pengguna serentak, bukan jumlah pengguna

Mulakan dengan jumlah pengguna yang aktif pada masa yang sama. Ini adalah jumlah yang memacu beban pelayan. Sebuah perniagaan dengan 50 pengguna yang dinamakan mungkin hanya mempunyai 18 hingga 25 yang disambungkan secara serentak semasa waktu puncak. Apabila menentukan saiz hos sesi, jumlah sesi serentak adalah jauh lebih berguna daripada jumlah keseluruhan.

Sebelum menguji kapasiti dunia nyata yang mampan di bawah beban, perancangan perlu mencabar anggaran.

Langkah 2: Klasifikasikan beban kerja sebagai ringan, sederhana atau berat

Seterusnya, susun pengguna kumpulan mengikut beban kerja. Microsoft’s panduan hos sesi semasa mencadangkan julat ketumpatan asas berikut untuk persekitaran multi-sesi dan HP serta sumber lain bersetuju:

• sehingga 6 pengguna ringan setiap vCPU,
• 4 pengguna sederhana setiap vCPU dan
• 2 pengguna berat setiap vCPU,

dengan masing-masing contoh VM minimum 8 vCPU, 16 GB RAM, 32 GB storan merentasi jalur beban kerja tersebut. Cadangan juga termasuk mengekalkan saiz VM sesi pelbagai antara 4 dan 24 vCPU untuk pulangan kapasiti yang lebih baik.

Peta beban kerja yang mudah untuk perancangan SMB akan membimbing pengurusan pengisihan:

• Cahaya: satu aplikasi perniagaan, penggunaan pelayar terhad, sesi pendek
• Sederhana: Aplikasi pejabat, tab pelayar, alat PDF, multitasking sederhana
• Berat: ERP, fail Excel yang lebih besar, penggunaan pelayar yang berterusan, pencetakan, pelbagai aplikasi dibuka sepanjang hari

Ini adalah jalur perancangan asas, bukan jaminan. Tujuannya adalah untuk memilih titik permulaan yang berasaskan tingkah laku beban kerja.

Langkah 3: Anggarkan kapasiti CPU

Setelah pengguna dikelompokkan, anggarkan CPU dengan pendekatan pengguna-per-vCPU. Sebagai contoh, jika 24 pengguna serentak kebanyakannya adalah pengguna sederhana, garis dasar Microsoft sekitar 4 pengguna per vCPU mencadangkan untuk memulakan sekitar 6 vCPU, kemudian membundarkan kepada saiz hos yang praktikal dengan ruang tambahan. Jika anda ingin memberikan kapasiti tambahan yang lebih baik semasa lonjakan permintaan CPU jangka pendek, rancang nisbah pengguna-per-inti yang lebih rendah daripada yang mungkin anda lakukan.

Seperti yang mungkin telah menjadi jelas, penentuan saiz CPU tidak seharusnya berhenti pada minimum matematik. Ia harus mengambil kira lonjakan log masuk, aktiviti antivirus, pekerjaan pelaporan dan tempoh pendek pelancaran aplikasi secara serentak.

Langkah 4: Anggarkan keperluan RAM

RAM harus memenuhi keperluan sistem operasi, perkhidmatan teras, overhead sesi dan penggunaan memori aplikasi bagi setiap pengguna. Seperti yang diterangkan di atas, garis dasar multi-sesi Microsoft semasa menggabungkan contoh beban kerja ringan, sederhana dan beratnya dengan minimum 16 GB RAM untuk titik permulaan 8 vCPU. Walaupun ini hanya garis dasar, ia tetap memberikan titik permulaan yang nyata untuk anggaran.

Kaedah praktikal dalam perniagaan kecil atau sederhana adalah untuk:

1. menyimpan memori untuk OS dan perkhidmatan platform,
2. anggaran memori setiap sesi mengikut kelas pengguna,
3. darab dengan sesi serentak,
4. kemudian tambahkan margin keselamatan.

PeteNetLive memberikan sebuah peraturan jari yang sengaja luas dari 2 hingga 8 GB setiap pengguna untuk perancangan RAM Host Sesi RD. Ini berguna sebagai peringatan terhadap meremehkan sesi berat, walaupun jumlah yang tepat mesti diperhalusi dalam ujian.

Langkah 5: Semak penyimpanan dan overhead profil

Penyimpanan sering kali diabaikan dalam perancangan pelayan terminal. Penyimpanan yang perlahan dan tersumbat boleh merosakkan logon, pemuatan profil, fail sementara, pelancaran aplikasi dan penampalan cetakan walaupun CPU dan RAM masih kelihatan boleh diterima.

• penyimpanan profil
• Penyimpanan OS
• log: untuk tujuan keselamatan dan lain-lain

Kategori terakhir ini sangat berharga untuk dianggarkan kerana ia boleh berkembang dengan cepat bergantung kepada saiz infrastruktur anda dan jenis pemantauan serta perlindungan yang anda perlukan.

Persembahan peranan demi peranan PeteNetLive berfungsi sebagai pengingat berguna bahawa hos sesi biasanya adalah tempat tekanan sumber muncul terlebih dahulu, sementara peranan RDS lain sering mempunyai jejak yang relatif lebih kecil. Ingat ini ketika anda mencari penanda kapasiti penggunaan syarikat anda, kerana ia dapat membantu dalam menyokong perancangan saiz.

Langkah 6: Tambah ruang untuk puncak, pertumbuhan dan pemulihan

Tiada kalkulator pelayan terminal yang seharusnya berakhir dengan nombor "cukup sahaja". Tambahkan ruang tambahan untuk:

• lonjakan tanda masuk pagi
• penampalan dan imbasan AV
• puncak laporan bulanan
• pertumbuhan pengguna yang diharapkan
• kegagalan hos dalam reka bentuk pelayan pelbagai

Sebagai penutup, beberapa nasihat operasi yang baik untuk mana-mana persekitaran yang bergerak melebihi satu hos adalah untuk mengambil kira hos tambahan sekiranya berlaku kehilangan pelayan atau hipervisor.

Kaedah Pengira Pelayan Terminal Mudah untuk SMB dan MSP

Logik kalkulator ini sengaja dibuat sederhana. Ia bertujuan untuk menghasilkan anggaran awal yang boleh dipertahankan, bukan penanda aras akhir, dan untuk anda menyesuaikannya dengan sewajarnya.

Formula perancangan cepat

Gunakan urutan ini:

1. Kira pengguna serentak .
2. Susun mereka ke dalam ringan, sederhana dan berat kumpulan.
3. Anggaran CPU menggunakan nisbah pengguna-per-vCPU asas.
4. Anggaran RAM dari overhead OS ditambah permintaan setiap sesi.
5. Semak penyimpanan untuk profil, prestasi sementara dan pelancaran.
6. Tambah 20 hingga 30 peratus ruang tambahan , kemudian semak keperluan failover.

Ini mencerminkan inti bagaimana saiz dibingkai secara umum: beban kerja pertama, nisbah kedua, penambahbaikan selepas pemerhatian. Dan sekarang, mengapa tidak mendapatkan pratonton awal tentang apa bentuk yang mungkin diambil dapatkan anggaran yang tepat dan merancang infrastruktur potensi anda? Alat utama ketika merancang bajet anda.

Contoh 1: 15 pengguna pejabat ringan

Anggap 15 pengguna serentak mengakses aplikasi perniagaan yang diterbitkan ditambah penggunaan pelayar ringan.

Menggunakan garis dasar cahaya yang disyorkan, anggaran CPU mentah adalah sekitar 3 vCPU. Dalam praktiknya, itu terlalu ketat untuk kapasiti lonjakan, jadi seorang perancang akan beralih kepada profil hos yang lebih praktikal daripada membina hingga ke tepi. Anda akan mendapati nasihat menyokong julat saiz 4 hingga 24 vCPU yang lebih luas dengan 8 vCPU, 16 GB RAM sebagai profil garis dasar standard untuk beban kerja sesi berganda.

Untuk RAM, simpan kapasiti untuk OS dan perkhidmatan, kemudian tambahkan memori sesi untuk setiap pengguna. Jika persekitaran stabil dan penggunaan aplikasi terhad, ini boleh muat dengan selesa pada hos yang sederhana, tetapi ia masih perlu disahkan semasa penggunaan percubaan.

Contoh 2: 30 pengguna pejabat dan ERP campuran

Anggaplah:

• 18 pengguna sederhana
• 12 pengguna berat

Jalan pintas perancangan akan menganggap kumpulan sederhana pada kira-kira 4 pengguna setiap vCPU dan kumpulan berat pada kira-kira 2 pengguna setiap vCPU. Ini menunjukkan kira-kira 4.5 vCPUs untuk kumpulan sederhana dan 6 vCPUs untuk kumpulan berat, sebelum overhead dan ruang tambahan. Dalam amalan, ini sudah menunjukkan arah jauh dari satu hos yang bersaiz ringan dan ke arah sama ada hos yang lebih besar dengan margin atau pembahagian merentasi beberapa hos sesi.

Ini adalah di mana nasihat "rancang untuk sumber pelayan" menjadi bermakna. Dengan sebuah ERP seperti dalam konteks perusahaan mana pun, tujuannya bukan hanya untuk menempatkan pengguna di suatu tempat. Matlamatnya bukan sekadar untuk menempatkan pengguna di suatu tempat. Matlamatnya adalah untuk memastikan masa respons yang boleh diterima semasa waktu paling sibuk dalam sehari.

Contoh 3: Bila untuk membahagikan pengguna di antara beberapa hos

Setelah pengiraan menghasilkan hos padat dengan kapasiti letupan terhad, jawapan yang lebih baik mungkin bersifat seni bina daripada penskalaan menegak. Hos sesi boleh ditetapkan untuk melakukan kerja berat, sementara peranan seperti RD Connection Broker, Gateway dan Pelesenan diberikan profil sumber yang berbeza. Memecahkan beban pengguna merentasi beberapa hos mungkin akan meningkatkan ketahanan, fleksibiliti penyelenggaraan dan perancangan pemulihan.

Bagi MSP, ini sering menjadi titik perubahan di mana kalkulator pelayan terminal menjadi perbincangan saiz ladang dan bukannya perbincangan pelayan tunggal.

Apakah Kesilapan Saiz Biasa yang Biasanya Mengganggu Prestasi Pelayan Terminal?

Kesilapan saiz biasanya tidak disebabkan oleh matematik semata-mata. Ia datang daripada andaian yang tidak betul.

Mengelirukan pelesenan dengan kapasiti prestasi

Pelesenan memberitahu anda bagaimana akses diberikan dan dikonfigurasikan. Ia tidak memberitahu anda berapa banyak pengguna serentak yang akan disokong oleh pelayan dengan prestasi yang boleh diterima.

Mengabaikan sesi yang berat pada pelayar dan berat pada cetakan

Banyak persekitaran masih meremehkan betapa banyak beban penggunaan pelayar moden, pengendalian PDF dan pencetakan boleh menambah kepada hos sesi. Aktiviti-aktiviti ini boleh mengalihkan kumpulan pengguna dari ringan ke sederhana, atau dari sederhana ke berat, walaupun aplikasi barisan perniagaan itu sendiri adalah sederhana.

Hanya saiz untuk beban purata

Purata beban jarang menjadi saat pengguna mengadu. Aduan berlaku semasa ribut logon, pembukaan fail serentak, larian laporan atau puncak pagi. Microsoft mencatat kapasiti letupan yang lebih baik adalah penting pada nisbah pengguna-per-teras yang lebih rendah kerana ia menyokong meninggalkan ruang daripada menyasarkan kepadatan maksimum.

Melupakan baki tumpukan RDS

Hos sesi adalah pengguna sumber utama, tetapi ia bukan satu-satunya peranan dalam persekitaran. Pembahagian peranan PeteNetLive adalah pengingat berguna untuk mengambil kira Connection Broker, Gateway, Akses Web dan Pelesenan secara berasingan apabila penyebaran berkembang melebihi penyediaan hos tunggal yang kecil.

Mengapa Pemantauan Perlu Mengesahkan Anggaran Saiz Anda?

Pengira pelayan terminal memberikan anda garis dasar perancangan. Ia tidak memberikan anda bukti. Untuk bukti, anda perlu memantau penggunaan.

Dari garis dasar ke bukti: pemantauan sebagai yang penting

Dalam artikel kami sebelum ini, kami menerangkan mengapa kapasiti pengguna yang mampan adalah soalan pemantauan yang praktikal. Di sini, tujuannya adalah untuk menunjukkan cara menganggarkan versi pertama kapasiti tersebut sebelum pelaksanaan. Pemantauan akan memperoleh banyak pengiraan yang telah kami sebutkan. Kami mengesyorkan anda menguji dalam konteks makmal untuk menilai keperluan yang anda bayangkan.

Di manakah TSplus Server Monitoring memberikan perbezaan?

Pemantauan Server TSplus sesuai setelah anggaran saiz dilaksanakan. Ia membantu mengesahkan sama ada pemadatan CPU, tekanan memori, penyumbatan storan atau lonjakan penggunaan sepadan dengan andaian yang digunakan dalam perancangan. Ini sangat berguna untuk pentadbir IT SMB dan MSP yang memerlukan bukti sebelum mengubah saiz hos, mengagihkan semula pengguna atau menambah pelayan lain.

Selain mengetahui cara untuk memproyeksikan sumber, bagaimana lagi anda boleh mengetahui sama ada pengiraan itu betul selain melalui sistem pemantauan? Server Monitoring memberikan anda pemantauan masa nyata dan amaran untuk memastikan anda sentiasa dimaklumkan apabila penanda mencapai ambang yang telah ditetapkan. .

Perisian TSplus untuk penghantaran aplikasi dan desktop yang selamat dan berterusan

TSplus Remote Access adalah lapisan penghantaran dalam cerita yang lebih luas sementara Advanced Security direka khas untuk melindungi pelayan aplikasi. Selain itu, TSplus Remote Support menyediakan kit asas untuk menyelesaikan masalah dan menyelenggara pelayan ini dan lebih banyak lagi dari mana-mana lokasi. Setelah persekitaran disesuaikan dengan betul, TSplus Remote Access akan menerbitkan desktop dan aplikasi dengan lebih mudah daripada Citrix dan tanpa melebihi bajet anda. Menguji ciri seperti akses web dan penghantaran terpusat akan memberikan anda rasa bagaimana anda boleh bergerak melepasi akses RDP ad hoc.

Kesimpulan

Pengira pelayan terminal tidak seharusnya menjanjikan jawapan ajaib. Sekarang adalah masa untuk mengira sumber pelayan terminal secara berperingkat: mulakan dengan pengguna serentak, klasifikasikan intensiti beban kerja, anggarkan CPU dan RAM berdasarkan tingkah laku sesi yang realistik, semak penyimpanan dan kemudian tambahkan margin untuk puncak, pertumbuhan dan pemulihan.

Sebagai pentadbir sistem, pentadbir IT SMB atau MSP, ini akan memberikan anda anggaran awal yang praktikal. Dari situ, disiplin sebenar adalah pengesahan. Rancang dengan teliti, laksanakan dengan berhati-hati dan kemudian gunakan data pemantauan untuk mengesahkan sama ada hos, atau ladang hos dapat mengekalkan pengalaman pengguna yang anda inginkan.