چگونه منابع را در یک سرور ترمینال محاسبه کنیم: یک روش اندازه‌گیری عملی

یک ماشین حساب سرور ترمینال به ندرت یک ماشین حساب واقعی است. در بیشتر محیط‌های SMB و MSP، این یک روش برنامه‌ریزی است که برای تخمین اینکه یک سرور ترمینال به چه مقدار CPU، RAM، ذخیره‌سازی و فضای اضافی نیاز دارد قبل از اینکه کاربران شروع به شکایت کنند، استفاده می‌شود. سوال واقعی پشت کلمه کلیدی عملی است: چگونه می‌توانید منابع را به اندازه کافی بر روی یک سرور ترمینال محاسبه کنید تا با اطمینان مستقر شوید، از هزینه‌های اضافی جلوگیری کنید و کاهش ریسک گلوگاه‌های عملکرد ?

یک محاسبه‌گر سرور ترمینال باید در واقع چه چیزی را محاسبه کند؟

یک ماشین حساب مفید برای سرورهای ترمینال باید بیش از "کاربران در هر سرور" را تخمین بزند. به عنوان یک مدیر، باید به شما در برنامه‌ریزی برای CPU، RAM، عملکرد ذخیره‌سازی، ذخیره‌سازی پروفایل و حاشیه ظرفیت تحت استفاده همزمان واقعی کمک کند. راهنمایی مایکروسافت برای میزبان‌های جلسه Remote Desktop اندازه‌گیری را بر اساس نوع بار کاری و کاربران پیشنهادی در هر vCPU، نه بر اساس یک محدودیت اتصال عمومی و یکسان، چارچوب‌بندی می‌کند.

چرا تعداد کاربران به تنهایی برای محاسبه منابع در یک سرور ترمینال کافی نیست؟

استفاده از جلسه

به یاد داشته باشید، دو محیط با همان تعداد کاربر می‌توانند نتایج بسیار متفاوتی تولید کنند. ما فرض می‌کنیم که شما قبلاً می‌دانید چند کاربر به زیرساخت شما دسترسی خواهند داشت، بنابراین داشتن مجوزها و CALs در نظر گرفته شده‌اند کار عملی می‌تواند آغاز شود.

تصور کنید که چگونه پانزده کاربر که یک برنامه تجاری را باز می‌کنند، ممکن است بار متوسطی بر روی یک میزبان ایجاد کنند. در عین حال، پانزده کاربر که یک دسکتاپ از راه دور کامل با مرورگرها، برنامه‌های Office، ابزارهای PDF، چاپ و همگام‌سازی پس‌زمینه را اجرا می‌کنند، می‌توانند اثر بسیار سنگین‌تری ایجاد کنند. مدل‌های اندازه‌گیری این تفاوت را با تفکیک بارهای چند جلسه‌ای سبک، متوسط و سنگین نشان می‌دهند.

تمایز مهم است زیرا "۳۰ کاربر" به تنهایی یک عدد ظرفیت نیست. این تنها زمانی معنی‌دار است که شما تعریف کنید کارهایی که آن کاربران انجام می‌دهند و استفاده می‌کنند در زمان اوج مصرف.

استفاده از سرور

همچنین به یک تمایز مهم که بسیار حائز اهمیت است، توجه کنید: برای آزمایشگاه‌ها یا یک دفتر کوچک، ممکن است یک سرور واحد برنامه‌ریزی کنید، زیرا تعداد کمتری از جلسات کاربری همزمان را اجرا خواهد کرد، در حالی که برای تولید، احتمالاً یک مزرعه برنامه‌ریزی خواهید کرد. در واقع، نقش‌های جداگانه برای بهبود عملکرد، ساده‌سازی عیب‌یابی و قفل کردن امنیت مورد نیاز است، بنابراین یک تقسیم‌بندی رایج می‌تواند باشد:

• یک سرور برای کارگزار، وب و مجوزدهی
• یک یا چند سرور برای میزبان جلسه
• یک RD Gateway بر روی سرور خود برای دسترسی خارجی.

برای یک قدم جلوتر رفتن، شما همچنین متوجه خواهید شد که نوع سرور، حافظه و غیره نیز در اینجا نقش خواهند داشت و ممکن است بخواهید در راه‌اندازی‌های بزرگ‌تر SSD را شامل کنید به عنوان مثال. با این حال، این فقط یک اشاره است تا شما را از امکانات آگاه کند.

چهار ورودی که برنامه‌ریزی منابع را شکل می‌دهند کدامند؟

بعدی، قابل اعتمادتر از پرش به شماره‌های سخت‌افزاری، در اینجا چهار ورودی برای جمع‌آوری قبل از شروع به شمارش وجود دارد. این کار بالادستی از تداخل با سوالات مربوط به مجوزها درباره اینکه چه کسی ممکن است متصل شود و تحت چه قوانینی از مایکروسافت جلوگیری می‌کند. نگرانی اصلی در اینجا این است که یک میزبان جلسه به چه مقدار منبع نیاز دارد تا پاسخگو بماند. مقاله قبلی ما به این موضوع پرداخت. مجوزدهی و ظرفیت سرور بنابراین می‌توانیم در اینجا جزئیات روش شمارش همه چیز را به‌طور سیستماتیک توسعه دهیم تا به‌درستی برنامه‌ریزی کنیم.

بنابراین، شما باید جمع کنید:

کاربران فعال همزمان

ما هنوز به این عدد اساسی نیاز داریم زیرا تعداد جلساتی که به طور همزمان اجرا می‌شوند قطعاً بر عملکرد سرور تأثیر خواهد گذاشت. توجه داشته باشید که تعداد همزمان می‌تواند مستقل از تعداد کل باشد.

کلاس بار کاری به ازای گروه کاربری

ارزیابی اینکه یک کاربر یا مجموعه‌ای از کاربران چقدر از منابع استفاده خواهند کرد، اولین بررسی واقعیت است. گروه‌ها یا افراد خاصی به طور حتم بیشتر از وظایفی که انجام می‌دهند، استفاده خواهند کرد. به همین دلیل است که کاربران سنگین نیاز به شناسایی دارند.

نوع برنامه و جلسه

همچنین بسیار مفید است که برنامه‌های خاصی را شناسایی کنید، زیرا برخی از کاربران بر اساس برنامه‌هایی که اجرا می‌کنند، مقادیر زیادی از منابع را تصاحب خواهند کرد.

اوج، رشد و حاشیه شکست

این لیست ورودی‌ها را با در نظر گرفتن حداکثر استفاده، به‌گونه‌ای گرد کنید که فضایی برای رشد کوتاه‌مدت مورد انتظار و ایجاد حاشیه‌ای برای پشتیبانی در نظر گرفته شود.

چگونه منابع را در سرورهای ترمینال محاسبه می‌کنید؟

در اینجا یک روش محاسباتی عملی وجود دارد که امیدواریم در مدیریت SMB و همچنین در زمینه‌های دیگر مفید باشد. هدف آن حداقل ساده‌سازی برنامه‌ریزی و ساختار آماده‌سازی است. سپس، باید بعداً به بهبود آن بپردازید تا بتوانید به آن در دوره آزمایشی و بعد از آن تکیه کنید.

مرحله ۱: شمارش کاربران همزمان، نه کاربران کل

تعداد کاربرانی را که همزمان فعال هستند، شروع کنید. این عدد بار سرور را تعیین می‌کند. یک کسب‌وکار با ۵۰ کاربر نام‌برده ممکن است تنها ۱۸ تا ۲۵ کاربر را در ساعات اوج به‌طور همزمان متصل داشته باشد. هنگام اندازه‌گیری یک میزبان جلسه، تعداد جلسات همزمان بسیار مفیدتر از کل تعداد کاربران است.

قبل از آزمایش ظرفیت پایدار در دنیای واقعی تحت بار، برنامه‌ریزی باید تخمین‌ها را به چالش بکشد.

مرحله ۲: بارهای کاری را به سبک، متوسط یا سنگین طبقه‌بندی کنید

بعد، کاربران گروه را بر اساس بار کاری مرتب کنید. مایکروسافت راهنمایی میزبان جلسه جاری چنین دامنه‌های چگالی پایه‌ای را برای محیط‌های چند جلسه‌ای پیشنهاد می‌کند و منابع HP و دیگر منابع نیز با آن موافقند:

• تا ۶ کاربر سبک به ازای هر vCPU،
• ۴ کاربر متوسط به ازای هر vCPU و
• ۲ کاربر سنگین به ازای هر vCPU،

با توجه به یک مثال حداقلی VM با ۸ vCPU، ۱۶ گیگابایت RAM و ۳۲ گیگابایت فضای ذخیره‌سازی در این باندهای بار کاری. توصیه‌ها همچنین شامل نگه‌داشتن اندازه‌های VM چند جلسه‌ای به طور تقریبی بین ۴ تا ۲۴ vCPU برای بازدهی بهتر ظرفیت است.

نقشه ساده بار کاری برای برنامه‌ریزی SMB به این ترتیب راهنمایی برای مرتب‌سازی خواهد بود:

• نور: یک برنامه کسب و کار، استفاده محدود از مرورگر، جلسات کوتاه
• متوسط: برنامه‌های اداری، زبانه‌های مرورگر، ابزارهای PDF، چندوظیفگی متوسط
• سنگین: ERP، فایل‌های بزرگ‌تر اکسل، استفاده مداوم از مرورگر، چاپ، چندین برنامه باز در طول روز

اینها باندهای برنامه‌ریزی پایه هستند، نه تضمین‌ها. هدف این است که یک نقطه شروع مبتنی بر رفتار بار کاری انتخاب شود.

مرحله ۳: برآورد ظرفیت CPU

پس از گروه‌بندی کاربران، با رویکرد کاربران به ازای هر vCPU، CPU را تخمین بزنید. به عنوان مثال، اگر ۲۴ کاربر همزمان عمدتاً کاربران متوسط باشند، خط پایه مایکروسافت که حدود ۴ کاربر به ازای هر vCPU است، پیشنهاد می‌کند که از حدود ۶ vCPU شروع کنید و سپس به اندازه میزبان عملی با فضای اضافی گرد کنید. اگر می‌خواهید ظرفیت اضافی بهتری در طول اوج تقاضای کوتاه‌مدت CPU ارائه دهید، نسبت‌های کاربران به ازای هر هسته را کمتر از آنچه که ممکن است در نظر بگیرید، برنامه‌ریزی کنید.

همانطور که ممکن است واضح شده باشد، اندازه‌گیری CPU نباید به حداقل ریاضی محدود شود. این باید شامل اوج‌های ورود، فعالیت آنتی‌ویروس، کارهای گزارش‌گیری و دوره‌های کوتاه راه‌اندازی همزمان برنامه‌ها باشد.

مرحله ۴: برآورد نیازهای RAM

RAM باید نیازهای سیستم عامل، خدمات اصلی، بار اضافی جلسه و استفاده از حافظه برنامه را برای هر کاربر پوشش دهد. همانطور که در بالا توضیح داده شد، خط پایه چند جلسه‌ای فعلی مایکروسافت نمونه‌های بار کاری سبک، متوسط و سنگین خود را با حداقل 16 گیگابایت RAM برای یک نقطه شروع 8 vCPU جفت کرده است. اگرچه این فقط یک خط پایه است، اما با این حال یک نقطه شروع ملموس برای برآورد ارائه می‌دهد.

یک روش عملی در یک کسب و کار کوچک یا متوسط این است که:

1. حافظه را برای سیستم عامل و خدمات پلتفرم رزرو کنید.
2. برآورد حافظه در هر جلسه بر اساس کلاس کاربر،
3. ضرب در جلسات همزمان،
4. سپس یک حاشیه ایمنی اضافه کنید.

پی نت لایو یک قاعده کلی عمدی و وسیع از ۲ تا ۸ گیگابایت به ازای هر کاربر برای برنامه‌ریزی RAM میزبان جلسه RD. این به عنوان یک هشدار در برابر دست کم گرفتن جلسات سنگین مفید است، حتی اگر تعداد دقیق باید در آزمایش تصحیح شود.

مرحله ۵: بررسی ذخیره‌سازی و بار پروفایل

ذخیره‌سازی اغلب در برنامه‌ریزی سرور ترمینال دست کم گرفته می‌شود. ذخیره‌سازی کند و مسدود شده می‌تواند به ورود به سیستم، بارگذاری پروفایل، فایل‌های موقت، راه‌اندازی برنامه‌ها و صف چاپ آسیب برساند حتی زمانی که CPU و RAM هنوز قابل قبول به نظر می‌رسند.

• ذخیره‌سازی پروفایل
• ذخیره‌سازی سیستم‌عامل
• گزارش‌ها: برای امنیت و سایر اهداف مشابه

این دسته آخر به خوبی ارزش تخمین زدن را دارد زیرا می‌تواند به سرعت با توجه به اندازه زیرساخت شما و نوع نظارت و حفاظتی که نیاز دارید، افزایش یابد.

ارائه نقش به نقش PeteNetLive به عنوان یک یادآوری مفید عمل می‌کند که میزبان جلسه معمولاً جایی است که فشار منابع ابتدا ظاهر می‌شود، در حالی که سایر نقش‌های RDS معمولاً ردپای نسبتاً کوچکتری دارند. این نکته را در نظر داشته باشید زمانی که به دنبال نشانه‌هایی از ظرفیت استفاده شرکت خود هستید، زیرا این می‌تواند در حمایت از اندازه‌گیری برنامه‌ها کمک کند.

مرحله ۶: فضای اضافی برای اوج‌ها، رشد و پشتیبانی اضافه کنید

هیچ محاسبه‌گر سرور ترمینال نباید با عدد "فقط به اندازه کافی" پایان یابد. فضای اضافی برای اضافه کنید:

• افزایش ورود در صبح
• پچینگ و اسکن‌های آنتی‌ویروس
• اوج‌های گزارش‌دهی ماهانه
• رشد مورد انتظار کاربران
• خطای میزبان در یک طراحی چند سروری

در پایان، برخی نکات عملی خوب برای هر محیطی که فراتر از یک میزبان واحد می‌رود، این است که میزبان‌های اضافی را در نظر بگیرید در صورت از دست دادن سرور یا هایپر وایزر.

روش ساده محاسبه سرور ترمینال برای SMBها و MSPها

این منطق محاسبه به عمد ساده است. هدف آن تولید یک برآورد اولیه قابل دفاع است، نه یک معیار نهایی، و برای شماست که آن را به طور مناسب تنظیم کنید.

یک فرمول برنامه‌ریزی سریع

از این توالی استفاده کنید:

1. تعداد کاربران همزمان .
2. آنها را مرتب کنید سبک، متوسط و سنگین گروه‌ها.
3. برآورد سی‌پی‌یو استفاده از نسبت کاربران به vCPU پایه.
4. برآورد رمز تصادفی از بار اضافی سیستم عامل به علاوه تقاضای هر جلسه.
5. بررسی کنید ذخیره‌سازی برای پروفایل، عملکرد موقت و راه‌اندازی.
6. افزودن ۲۰ تا ۳۰ درصد فضای اضافی سپس نیازهای انتقال را بررسی کنید.

این بازتابی از جوهره نحوه اندازه‌گیری به طور کلی است: بار کاری اول، نسبت‌ها دوم، تصحیح پس از مشاهده. و حالا، چرا نگاهی اجمالی به شکل آن چه می‌تواند باشد ، برآورد دقیقی به دست آورید و زیرساخت بالقوه خود را ترسیم کنید؟ ابزاری کلیدی هنگام برنامه‌ریزی بودجه شما.

مثال ۱: ۱۵ کاربر اداری سبک

فرض کنید ۱۵ کاربر همزمان به یک برنامه تجاری منتشر شده دسترسی دارند به علاوه استفاده سبک از مرورگر.

با استفاده از خطوط پایه سبک توصیه شده، تخمین خام CPU حدود ۳ vCPU است. در عمل، این برای ظرفیت انفجاری بسیار تنگ است، بنابراین یک برنامه‌ریز به یک پروفایل میزبان عملی‌تر تغییر می‌دهد تا اینکه به لبه نزدیک شود. شما خواهید دید که مشاوره به یک دامنه اندازه‌گیری وسیع‌تر ۴ تا ۲۴ vCPU با ۸ vCPU و ۱۶ گیگابایت RAM به عنوان یک پروفایل پایه استاندارد برای بارهای کاری چند جلسه‌ای تمایل دارد.

برای RAM، ظرفیت را برای سیستم‌عامل و خدمات رزرو کنید، سپس حافظه جلسه را برای هر کاربر اضافه کنید. اگر محیط پایدار باشد و استفاده از برنامه محدود باشد، این می‌تواند به راحتی بر روی یک میزبان متوسط جا بگیرد، اما باید در طول استفاده آزمایشی همچنان تأیید شود.

مثال ۲: ۳۰ کاربر مختلط اداری و ERP

فرض کنید:

• ۱۸ کاربر متوسط
• ۱۲ کاربر سنگین

یک میانبر برنامه‌ریزی گروه متوسط را به طور تقریبی ۴ کاربر به ازای هر vCPU و گروه سنگین را به طور تقریبی ۲ کاربر به ازای هر vCPU در نظر می‌گیرد. این به معنای حدود ۴.۵ vCPU برای گروه متوسط و ۶ vCPU برای گروه سنگین است، قبل از اضافه بار و فضای اضافی. در عمل، این به وضوح به سمت یک میزبان با اندازه کم واحد و به سمت یک میزبان بزرگ‌تر با حاشیه یا تقسیم بر روی چندین میزبان جلسه اشاره دارد.

این جایی است که توصیه "برنامه‌ریزی برای منابع سرور" معنا پیدا می‌کند. با یک ERP همانطور که در هر زمینه شرکتی، هدف فقط قرار دادن کاربران در جایی نیست. هدف فقط این نیست که کاربران را در جایی جا بدهیم. هدف این است که زمان‌های پاسخگویی را در شلوغ‌ترین ساعات روز قابل قبول نگه داریم.

مثال ۳: چه زمانی کاربران را بین چندین میزبان تقسیم کنیم

پس از اینکه محاسبه یک میزبان متراکم با ظرفیت انفجاری محدود تولید کرد، پاسخ بهتر ممکن است معماری باشد تا مقیاس‌پذیری عمودی. میزبان‌های جلسه می‌توانند برای انجام کارهای سنگین تنظیم شوند، در حالی که نقش‌هایی مانند RD Connection Broker، Gateway و Licensing می‌توانند پروفایل‌های منابع متفاوتی داشته باشند. تقسیم بار کاربران بین چندین میزبان احتمالاً به بهبود تاب‌آوری، انعطاف‌پذیری نگهداری و برنامه‌ریزی برای انتقال کمک می‌کند.

برای MSPها، این اغلب نقطه عطفی است که در آن یک محاسبه‌گر سرور ترمینال به یک بحث در مورد اندازه‌گیری مزرعه تبدیل می‌شود به جای یک بحث در مورد یک سرور واحد.

کدام اشتباهات رایج در اندازه‌گیری معمولاً عملکرد سرور ترمینال را مختل می‌کنند؟

خطاهای اندازه‌گیری معمولاً تنها ناشی از ریاضیات نیستند. آنها ناشی از فرضیات نادرست هستند.

مجوزدهی را با ظرفیت عملکرد اشتباه گرفتن

مجوزدهی به شما می‌گوید که دسترسی چگونه اختصاص داده و پیکربندی می‌شود. این به شما نمی‌گوید که یک سرور چند کاربر همزمان را با عملکرد قابل قبول پشتیبانی خواهد کرد.

عدم توجه به جلسات سنگین مرورگر و جلسات سنگین چاپ

بسیاری از محیط‌ها هنوز میزان بار ناشی از استفاده از مرورگرهای مدرن، مدیریت PDF و چاپ را بر روی یک میزبان جلسه دست کم می‌گیرند. این فعالیت‌ها می‌توانند یک گروه کاربری را از سبک به متوسط، یا از متوسط به سنگین منتقل کنند، حتی زمانی که خود برنامه خط کسب و کار متواضع باشد.

تنظیم اندازه فقط برای بار متوسط

بار متوسط به ندرت زمانی است که کاربران شکایت می‌کنند. شکایات در زمان طوفان‌های ورود، باز کردن همزمان فایل‌ها، اجرای گزارش‌ها یا اوج‌های صبحگاهی اتفاق می‌افتد. مایکروسافت به اهمیت ظرفیت انفجاری بهتر در نسبت‌های پایین‌تر کاربر به هسته اشاره می‌کند زیرا این امر از ایجاد فضای خالی به جای هدف‌گذاری حداکثر چگالی پشتیبانی می‌کند.

فراموش کردن بقیه پشته RDS

میزبان جلسه اصلی‌ترین مصرف‌کننده منابع است، اما تنها نقش در محیط نیست. تجزیه و تحلیل نقش PeteNetLive یادآوری مفیدی است تا به‌طور جداگانه به کارگزار اتصال، دروازه، دسترسی وب و مجوزها توجه شود زمانی که استقرار فراتر از یک تنظیم کوچک با یک میزبان واحد رشد می‌کند.

چرا باید نظارت بر برآوردهای اندازه‌گیری شما اعتبارسنجی کند؟

یک ماشین حساب سرور ترمینال به شما یک خط پایه برنامه‌ریزی می‌دهد. این ماشین حساب به شما مدرک نمی‌دهد. برای مدرک، شما نیاز دارید که استفاده را نظارت کنید.

از پایه تا اثبات: نظارت به عنوان یک اصل

در مقاله قبلی ما توضیح می‌دهیم که چرا ظرفیت پایدار کاربر یک سوال عملی در زمینه نظارت است. در اینجا، هدف نشان دادن چگونگی برآورد نسخه اول آن ظرفیت قبل از راه‌اندازی بوده است. نظارت برای شما بسیاری از شمارش‌هایی را که ذکر کرده‌ایم به دست خواهد آورد. ما توصیه می‌کنیم که در یک زمینه آزمایشگاهی تست کنید تا نیازهای مورد نظر خود را ارزیابی کنید.

TSplus Server Monitoring چه تفاوتی ایجاد می‌کند؟

نظارت بر سرور TSplus متناسب است پس از استقرار برآورد اندازه‌گیری. این به تأیید اینکه آیا اشباع CPU، فشار حافظه، گلوگاه‌های ذخیره‌سازی یا اوج‌های استفاده با فرضیات استفاده شده در برنامه‌ریزی مطابقت دارد، کمک می‌کند. این به‌ویژه برای مدیران IT SMB و MSPها که به شواهدی قبل از تغییر اندازه یک میزبان، توزیع مجدد کاربران یا افزودن یک سرور دیگر نیاز دارند، مفید است.

فراتر از دانستن نحوه تخصیص منابع، چگونه می‌توانید بدانید که آیا محاسبه درست بوده است جز از طریق سیستم‌های نظارتی؟ Server Monitoring به شما نظارت در زمان واقعی و هشدارهایی ارائه می‌دهد تا شما را در جریان نگه دارد هر زمان که نشانگرها به آستانه‌های تعیین شده شما برسند. .

نرم‌افزار TSplus برای تحویل امن و پایدار برنامه‌ها و دسکتاپ‌ها

TSplus Remote Access به عنوان لایه تحویل در داستان وسیع‌تر قرار دارد در حالی که Advanced Security به طور خاص برای محافظت از سرورهای برنامه طراحی شده است. علاوه بر این، TSplus Remote Support یک کیت ضروری برای عیب‌یابی و نگهداری این سرورها و بیشتر از هر مکان دیگری ارائه می‌دهد. هنگامی که محیط به درستی اندازه‌گیری شود، TSplus Remote Access دسکتاپ‌ها و برنامه‌ها را ساده‌تر از Citrix و بدون فراتر رفتن از بودجه شما منتشر خواهد کرد. آزمایش ویژگی‌هایی مانند دسترسی وب و تحویل متمرکز به شما طعم این را می‌دهد که چگونه می‌توانید فراتر از دسترسی RDP موردی حرکت کنید.

نتیجه

یک محاسبه‌گر سرور ترمینال نباید وعده یک پاسخ جادویی بدهد. اکنون زمان آن است که منابع سرور ترمینال را به صورت مرحله‌ای محاسبه کنیم: با کاربران همزمان شروع کنید، شدت بار کاری را طبقه‌بندی کنید، CPU و RAM را از رفتار واقعی جلسه تخمین بزنید، ذخیره‌سازی را بررسی کنید و سپس حاشیه‌ای برای اوج‌ها، رشد و پشتیبانی اضافه کنید.

به عنوان مدیر سیستم، مدیران IT SMB یا MSP، این به شما یک تخمین اولیه عملی می‌دهد. از آنجا، انضباط واقعی اعتبارسنجی است. به دقت برنامه‌ریزی کنید، به طور محافظه‌کارانه مستقر شوید و سپس از داده‌های نظارتی برای تأیید اینکه آیا میزبان، یا مزرعه میزبان می‌تواند تجربه کاربری که مد نظر دارید را حفظ کند.