خدمات کولوکیشن دیتاسنتر به سازمان‌ها اجازه می‌دهد سرورها و تجهیزات شبکه متعلق به خود را در یک مرکز داده مستقر کنند و از فضای رک، برق، سرمایش، اتصال شبکه و خدمات عملیاتی آن استفاده کنند. برای مدیر زیرساخت و CTO، تصمیم اصلی فقط انتخاب محل نگهداری سرور نیست؛ باید روشن شود چه ظرفیتی تحویل می‌گیرید، مسئولیت هر طرف چیست و هنگام اختلال چه تعهد قابل‌اندازه‌گیری وجود دارد.
این راهنما معیارهای انتخاب کولوکیشن، ارزیابی SLA، محاسبه Uptime، طراحی برق و شبکه، برآورد هزینه و برنامه مهاجرت را کنار هم قرار می‌دهد. هدف، تبدیل پیشنهاد تجاری دیتاسنتر به یک تصمیم فنی قابل دفاع است؛ نه انتخاب صرفاً بر اساس تعداد یونیت یا بالاترین درصد آپتایم تبلیغ‌شده.
خدمات کولوکیشن دیتاسنتر چیست و برای چه سازمانی مناسب است؟
در کولوکیشن، مالکیت سخت‌افزار معمولاً با مشتری است و دیتاسنتر محیط میزبانی آن را فراهم می‌کند. خرید قطعه، پیکربندی سیستم‌عامل، امنیت نرم‌افزار، مجازی‌سازی و بکاپ لزوماً بخشی از سرویس پایه نیستند. هر خدمتی فراتر از میزبانی فیزیکی باید در سفارش و ماتریس مسئولیت مشخص شود.
این مدل برای سازمانی جذاب است که تجهیزات اختصاصی دارد، به کنترل سخت‌افزار نیاز دارد یا می‌خواهد زیرساخت پایدار خود را خارج از اتاق سرور سازمان نگهداری کند. در مقابل، تیمی با تقاضای نامطمئن و توان عملیاتی محدود باید هزینه خرید تجهیزات و نگهداری را با اجاره سرور یا سرویس ابری مقایسه کند.
تفاوت کولوکیشن، سرور اختصاصی و ابر
| معیار | کولوکیشن | سرور اختصاصی اجاره‌ای | سرویس ابری |
|---|---|---|---|
| تأمین سخت‌افزار | معمولاً مشتری | ارائه‌دهنده | ارائه‌دهنده زیرساخت |
| کنترل تجهیزات | زیاد؛ در محدوده مقررات مرکز | وابسته به قرارداد | معمولاً در سطح منابع و سرویس‌ها |
| توسعه ظرفیت | خرید، حمل و نصب تجهیزات | سفارش و تأمین سرور | وابسته به سهمیه و ظرفیت سرویس |
| هزینه اولیه | سخت‌افزار و استقرار | معمولاً کمتر از خرید تجهیزات | وابسته به مدل مصرف و تعهد |
| مسئولیت عملیات | بخش مهمی با مشتری | وابسته به سطح مدیریت | وابسته به نوع سرویس |
اگر هنوز درباره مدل میزبانی تصمیم نگرفته‌اید، راهنمای مقایسه سرور مجازی و سرور اختصاصی نقطه شروع مناسبی برای بررسی تفاوت کنترل منابع و مسئولیت نگهداری است.
اجزای اصلی خدمات کولوکیشن دیتاسنتر
فضای رک، وزن و امکان توسعه
سرویس ممکن است بر اساس چند یونیت، بخشی از رک، رک کامل یا فضای محصور اختصاصی ارائه شود. یونیت فقط ارتفاع تجهیزات را بیان می‌کند؛ عمق رک، ظرفیت وزن، نوع ریل، فضای کابل‌کشی و دسترسی جلو و عقب نیز باید بررسی شوند. ظرفیت رشد را هم‌زمان برای فضا، برق و سرمایش رزرو کنید؛ رک نیمه‌خالی الزاماً ظرفیت نصب سرورهای پرمصرف جدید را ندارد.
برق و سرمایش قابل استفاده
توان قراردادی، توان قابل استفاده هر مدار و مصرف واقعی تجهیزات سه مفهوم متفاوت‌اند. مشخص کنید صورتحساب بر مبنای ظرفیت رزروشده، مصرف انرژی یا ترکیبی از آن‌ها محاسبه می‌شود. اندازه‌گیری دمای هوای ورودی سرور، نقاط داغ و روند مصرف برق برای بهره‌برداری مفیدتر از اتکا به یک عدد میانگین برای کل سالن است.
شبکه و خدمات عملیاتی
پهنای باند اینترنت، ارتباط اختصاصی، IP، اتصال متقاطع یا Cross-connect و خدمات Remote Hands می‌توانند اقلام جداگانه باشند. در ارزیابی خدمات کولوکیشن دیتاسنتر، فهرست اقلام مشمول هزینه پایه و اقلام قابل سفارش را مکتوب دریافت کنید. دسترسی شبانه‌روزی به تیکت نیز الزاماً به معنی حضور فوری تکنسین کنار رک نیست.
SLA خدمات کولوکیشن دیتاسنتر چه چیزی را باید پوشش دهد؟
SLA توافق سطح خدمت است: مشخص می‌کند چه خدمتی با چه معیار و در چه بازه‌ای سنجیده می‌شود و در صورت نقض تعهد چه فرایندی اجرا خواهد شد. عبارت «آپتایم بالا» بدون تعریف نقطه اندازه‌گیری، استثناها و نحوه ثبت قطعی، مبنای مناسبی برای مقایسه پیشنهادها نیست.
| بند قابل بررسی | پرسش کلیدی |
|---|---|
| دامنه تعهد | برق رک، شبکه، سرمایش یا مجموعه مشخصی از خدمات؟ |
| نقطه تحویل | اندازه‌گیری روی کدام پریز، پورت یا مرز شبکه انجام می‌شود؟ |
| دوره سنجش | ماه تقویمی، دوره صورتحساب یا بازه دیگری است؟ |
| تعریف اختلال | قطعی کامل، افت کیفیت و اختلال جزئی چگونه محاسبه می‌شوند؟ |
| استثناها | نگهداری برنامه‌ریزی‌شده و تجهیزات مشتری چه وضعیتی دارند؟ |
| پشتیبانی | زمان پاسخ اولیه با زمان بازگردانی خدمت چه تفاوتی دارد؟ |
| جبران خدمت | سقف اعتبار، مهلت درخواست و مدارک لازم چیست؟ |
| گزارش رخداد | گزارش علت ریشه‌ای و اقدام اصلاحی چه زمانی تحویل می‌شود؟ |
تفاوت SLA، SLO و SLI
SLI شاخص اندازه‌گیری است؛ مانند نسبت درخواست‌های موفق. SLO هدفی است که برای آن شاخص تعیین می‌کنید. SLA تعهد قراردادی و پیامد نقض آن را مشخص می‌کند. برای مثال، روشن بودن برق رک نمی‌تواند به‌تنهایی موفقیت ورود کاربران به سامانه را نشان دهد. رویکرد Google SRE در تعریف SLO بر انتخاب شاخص‌هایی نزدیک به تجربه کاربر تأکید دارد.
جبران مالی جای معماری پایدار را نمی‌گیرد
Service Credit معمولاً اعتبار خدمات طبق قرارداد است و نباید آن را معادل جبران همه خسارت تجاری فرض کرد. برای کسب‌وکار حساس، هزینه توقف فروش یا از دست رفتن عملیات ممکن است از مبلغ اعتبار بسیار بیشتر باشد. بنابراین خدمات کولوکیشن دیتاسنتر را همراه با طراحی افزونگی، بکاپ و برنامه بازیابی ارزیابی کنید.
محاسبه Uptime و زمان قطعی مجاز
برای یک شاخص زمان‌محور، اگر T مدت بازه مشمول سنجش و D مجموع زمان عدم دسترس‌پذیری مشمول باشد، فرمول ساده زیر کاربرد دارد. واحد T و D باید یکسان باشد و قطعی‌های هم‌پوشان برای همان خدمت دوبار شمرده نشوند.
Availability (%) = ((T − D) / T) × ۱۰۰
Allowed downtime = T × (۱ − Target availability / 100)
جدول زیر صرفاً تبدیل ریاضی درصد دسترس‌پذیری به زمان است؛ نه تعهد یک ارائه‌دهنده و نه پیش‌بینی تعداد رخدادها. فرض جدول، دوره کامل و بدون کسر استثناهاست.
| دسترس‌پذیری هدف | قطعی در ماه ۳۰روزه | قطعی در سال ۳۶۵روزه |
|---|---|---|
| ۹۹٫۹٪ | ۴۳ دقیقه و ۱۲ ثانیه | ۸ ساعت و ۴۵ دقیقه و ۳۶ ثانیه |
| ۹۹٫۹۵٪ | ۲۱ دقیقه و ۳۶ ثانیه | ۴ ساعت و ۲۲ دقیقه و ۴۸ ثانیه |
| ۹۹٫۹۹٪ | ۴ دقیقه و ۱۹٫۲ ثانیه | ۵۲ دقیقه و ۳۳٫۶ ثانیه |
| ۹۹٫۹۹۹٪ | ۲۵٫۹۲ ثانیه | ۵ دقیقه و ۱۵٫۳۶ ثانیه |
برای نمونه، ۲۰ دقیقه قطعی مشمول در یک ماه ۳۰روزه با ۴۳٬۲۰۰ دقیقه، دسترس‌پذیری حدود ۹۹٫۹۵۳۷ درصد می‌دهد. این نتیجه از هدف ۹۹٫۹۵٪ بالاتر و از ۹۹٫۹۹٪ پایین‌تر است. اگر قرارداد تعمیرات برنامه‌ریزی‌شده را مستثنا کند، روش محاسبه باید دقیقاً از همان قرارداد پیروی کند. رعایت یک هدف سالانه نیز به معنی رعایت آن در تک‌تک ماه‌ها نیست.
Tier دیتاسنتر چه تفاوتی با SLA دارد؟
Tier به ویژگی‌های طراحی و تاب‌آوری زیرساخت مرکز داده مربوط است؛ SLA تعهد ارائه‌دهنده درباره خدمت خریداری‌شده است. طبق توضیح رسمی Uptime Institute، استاندارد جاری توپولوژی برای سطوح Tier درصد دسترس‌پذیری پیش‌بینی‌شده تعیین نمی‌کند. بنابراین تبدیل مستقیم «Tier III» به یک آپتایم تضمینی ثابت، روش درستی برای ارزیابی قرارداد نیست.
در بررسی گواهی، نام دقیق سایت، دامنه ارزیابی و نوع گواهی را بخواهید. گواهی طراحی با تأیید تأسیسات ساخته‌شده یا ارزیابی عملیات یکسان نیست. عبارت‌هایی مانند «طراحی مطابق Tier» را نیز با گواهی صادرشده یکی نگیرید. برای شناخت چارچوب، صفحه رسمی گواهی‌های Tier مرجع مناسب‌تری از جدول‌های تبلیغاتی است.
برق افزونه در خدمات کولوکیشن دیتاسنتر
دو کابل برق همیشه دو مسیر مستقل نیست
دو منبع تغذیه سرور تنها زمانی ارزش افزونگی دارند که مسیر اتصال و ظرفیت باقی‌مانده نیز درست طراحی شده باشد. اتصال هر دو کابل به یک PDU یا مسیر مشترک می‌تواند نقطه خرابی مشترک بسازد. استقلال مسیرهای A و B را از نقطه تحویل تا محدوده‌ای که ارائه‌دهنده تعهد می‌کند بررسی کنید.
در مستندات برق فضای اختصاصی Equinix نیز بر این نکته تأکید شده که در یک جفت مدار افزونه، بار باید در ظرفیت یک مدار قابل تحمل باشد تا با خرابی مدار دیگر امکان ادامه کار وجود داشته باشد. مقادیر مجاز دقیق، به مدار، منطقه و قرارداد بستگی دارند.
نمونه ارزیابی ظرفیت پس از خرابی
فرض کنید بار واقعی تجهیزات رک ۴ کیلووات است. اگر بعد از قطع مسیر A، مسیر B فقط ۳ کیلووات ظرفیت قابل استفاده داشته باشد، داشتن دو مسیر مانع اضافه‌بار نخواهد شد. علاوه بر مصرف پایدار، رفتار تجهیزات هنگام راه‌اندازی و انتقال بار را هم بررسی کنید. ظرفیت نامی پاور سرور جای اندازه‌گیری مصرف واقعی را نمی‌گیرد.
N+1 و 2N را در سطح جزء مشخص بررسی کنید: UPS، سرمایش یا مسیر توزیع. یک برچسب افزونگی برای یک جزء، استقلال کل زنجیره را اثبات نمی‌کند. آزمون انتقال بار فقط باید با برنامه مصوب، هماهنگی دیتاسنتر و مسیر بازگشت انجام شود.
شبکه: ظرفیت، تنوع مسیر و کیفیت اتصال
در خرید خدمات کولوکیشن دیتاسنتر، سرعت پورت را با پهنای باند تعهدشده اشتباه نگیرید. پورت ۱۰ گیگابیتی به‌تنهایی تضمین نمی‌کند همین ظرفیت در اینترنت یا مسیر بین دو سایت قابل استفاده باشد. سقف ترافیک، مدل صورتحساب، ظرفیت داخلی و بین‌المللی و شرایط افزایش مصرف را جدا بررسی کنید.
- تأمین‌کنندگان بالادستی و نقاط مشترک مسیرهای ارتباطی را مشخص کنید.
- تنوع اپراتور را از تنوع مسیر فیزیکی فیبر جدا بدانید.
- تأخیر، Packet Loss و ظرفیت را از شبکه‌های مهم کاربران اندازه بگیرید.
- دامنه سرویس مقابله با DDoS، محدودیت‌ها و فرایند فعال‌سازی را بپرسید.
- هزینه و زمان تحویل Cross-connect، پورت و IP را دریافت کنید.
- برای شبکه مدیریت، دسترسی کنترل‌شده و مسیر خارج از باند طراحی کنید.
اگر از BGP و چند اتصال استفاده می‌کنید، مسئولیت اعلان مسیر، فیلترها و واکنش به خرابی باید روشن باشد. چند لینک بدون آزمون Failover، تضمین‌کننده بازیابی سریع نیستند.
امنیت فیزیکی و مرز مسئولیت‌ها
کنترل ورود، ثبت مراجعه، همراهی پیمانکار، مجوز خروج تجهیزات و نگهداری گزارش‌ها را در ارزیابی امنیت لحاظ کنید. وجود قفل رک به‌تنهایی درباره امنیت سیستم‌عامل، رمزنگاری داده یا دسترسی مدیریتی چیزی نمی‌گوید. برای تجهیزات خارج‌شونده نیز پاک‌سازی داده و زنجیره تحویل مستند لازم است.
| حوزه | مسئولیت معمول؛ نیازمند تأیید قراردادی |
|---|---|
| ساختمان، برق و سرمایش | ارائه‌دهنده در محدوده خدمت |
| سرور، قطعه یدکی و ضمانت سخت‌افزار | مشتری؛ مگر خدمت جداگانه خریداری شود |
| سیستم‌عامل، وصله و دسترسی | مشتری یا ارائه‌دهنده مدیریت‌شده طبق توافق |
| بکاپ و آزمون بازیابی | باید صریحاً به یک مالک مشخص واگذار شود |
| کابل و پورت تحویلی | بر اساس نقطه مرزی تعریف‌شده |
گواهی امنیتی را همراه با دامنه، محل تحت پوشش و اعتبار آن بررسی کنید. هیچ گواهی عمومی، جای ارزیابی نیازهای خاص سازمان شما و کنترل‌های روی تجهیزات خودتان را نمی‌گیرد.
Remote Hands، پشتیبانی و مدیریت رخداد
Remote Hands معمولاً برای اقدام‌های فیزیکی مشخص مانند بررسی چراغ وضعیت، اتصال کابل یا تعویض قطعه با دستورالعمل کاربرد دارد. مدیریت دیتابیس، تحلیل امنیت یا تغییر پیکربندی شبکه را نباید خودکار جزو آن فرض کرد. پیش از استقرار، فهرست اقدامات مجاز، سطح مهارت، هزینه خارج از ساعت و حداقل زمان صورتحساب را ثبت کنید.
برای رخداد بحرانی، مسیر ارتباطی جایگزین تیکت، مسئول تصمیم‌گیری و زنجیره Escalation داشته باشید. زمان تأیید دریافت درخواست، زمان حضور تکنسین، زمان ارائه راه‌حل موقت و زمان رفع کامل را جدا مطالبه کنید. دستورالعمل اجرایی باید شناسه رک، تصویر قطعه، مراحل تأیید و شرایط توقف عملیات را مشخص کند.
پایش Uptime از دید دیتاسنتر و کاربر
پایش خدمات کولوکیشن دیتاسنتر باید دست‌کم دو لایه داشته باشد: وضعیت برق، محیط و اتصال تحویلی؛ و سلامت واقعی برنامه مشتری. سنجش از یک نقطه داخل همان رک ممکن است اختلال دسترسی کاربران بیرونی را نشان ندهد. از نقاط متناسب با جامعه کاربران، آزمون مصنوعی عملیات مهم اجرا کنید.
داشبورد ماهانه بهتر است روند توان، ظرفیت باقی‌مانده، رخدادهای شبکه، زمان‌های پاسخ‌گویی و نتیجه آزمون بازیابی را کنار شاخص‌های برنامه نمایش دهد. زمان سیستم‌ها را هماهنگ نگه دارید و شواهد رخداد شامل زمان آغاز، پایان، اثر و شماره تیکت را ثبت کنید. روش اعتراض به اختلاف داده پایش شما و ارائه‌دهنده نیز باید مشخص باشد.
تداوم کسب‌وکار و بازیابی خارج از سایت
کولوکیشن جای بکاپ نیست و افزونگی داخل یک ساختمان همه ریسک‌های مشترک را حذف نمی‌کند. ابتدا RPO، یعنی هدف نقطه بازیابی و میزان قابل قبول از دست رفتن داده، و RTO، یعنی هدف زمان بازیابی، را برای هر سرویس تعیین کنید. سپس محل نسخه پشتیبان، استقلال حساب‌های مدیریتی و امکان بازیابی در مقصد دیگر را طراحی کنید.
دو سایت بدون تکثیر درست داده، ظرفیت کافی مقصد و آزمون جابه‌جایی سرویس، برنامه بازیابی کامل نمی‌سازند. وابستگی‌های DNS، احراز هویت، شبکه و سامانه صدور مجوز را نیز در تمرین بازیابی قرار دهید. معیار موفقیت، صرفاً روشن شدن ماشین نیست؛ عملیات اصلی کسب‌وکار باید دوباره قابل انجام باشد.
هزینه واقعی خدمات کولوکیشن دیتاسنتر
برای مقایسه پیشنهادها، یک سناریوی یکسان با تعداد رک، توان قابل استفاده، ظرفیت شبکه و سطح پشتیبانی یکسان بسازید. سپس هزینه کل مالکیت را در یک بازه مشترک محاسبه کنید. ارزان‌ترین هزینه هر یونیت ممکن است با برق، اتصال و خدمات عملیاتی گران‌تر همراه باشد.
- خرید و استهلاک سخت‌افزار، قطعات یدکی و ضمانت؛
- فضای رک، ظرفیت برق، مصرف انرژی و هزینه‌های راه‌اندازی؛
- پهنای باند، ترافیک اضافه، IP و Cross-connect؛
- خدمات Remote Hands، حمل تجهیزات و حضور نیرو؛
- لایسنس، امنیت، مانیتورینگ و بکاپ خارج از سایت؛
- هزینه رشد، تمدید، جمع‌آوری تجهیزات و خروج از قرارداد.
برای بارهای پایدار، مالکیت تجهیزات ممکن است توجیه اقتصادی داشته باشد؛ برای تقاضای متغیر، ظرفیت رزروشده بلااستفاده می‌تواند هزینه‌ساز شود. نتیجه را بر اساس مدل مصرف و افق برنامه‌ریزی خود محاسبه کنید، نه یک حکم کلی درباره ارزان‌تر بودن کولوکیشن.
چک‌لیست انتخاب و تحویل خدمات کولوکیشن دیتاسنتر
پیش از دریافت پیشنهاد
فهرست تجهیزات، یونیت و وزن، مصرف اندازه‌گیری‌شده، نیاز رشد، پورت‌ها، RPO/RTO و ساعات دسترسی را آماده کنید. نیازهای ضروری را از گزینه‌های مطلوب جدا کنید تا پیشنهادها قابل مقایسه شوند.
پیش از امضای قرارداد
نقشه نقاط تحویل، ظرفیت پس از خرابی، متن SLA، جدول مسئولیت و هزینه‌ها را بازبینی کنید. درباره تعمیرات برنامه‌ریزی‌شده، سابقه رخداد قابل ارائه، قطعه یدکی و خروج اضطراری تجهیزات پرسش مشخص داشته باشید. همه این موارد باید برای همان سایت و همان سرویس پیشنهادی پاسخ داده شوند.
در زمان استقرار و پذیرش
رک و کابل‌ها را برچسب‌گذاری و موجودی دارایی را ثبت کنید. مسیرهای برق و شبکه را با نقشه تطبیق دهید؛ سپس ارتباط مدیریتی، پایش، بار واقعی و فرایند پشتیبانی را آزمایش کنید. آزمون‌های اختلال را فقط در محدوده هماهنگ‌شده انجام دهید و نتیجه را به صورت‌جلسه پذیرش اضافه کنید.
پس از راه‌اندازی
مصرف و رخدادها را با فرضیات اولیه مقایسه کنید. پیش از پر شدن ظرفیت برق یا شبکه، درخواست توسعه بدهید. گزارش ماهانه SLA و تمرین دوره‌ای بازیابی را به بخشی از جلسه بهره‌برداری تبدیل کنید.
اشتباهات رایج در انتخاب کولوکیشن
- مقایسه قیمت رک بدون یکسان‌سازی توان و سطح شبکه؛
- برابر دانستن Tier با تضمین آپتایم برنامه؛
- استفاده از دو کابل متصل به یک مسیر مشترک؛
- فرض وجود بکاپ، مدیریت سیستم‌عامل یا DDoS Protection در سرویس پایه؛
- خرید چند لینک بدون بررسی استقلال مسیر و آزمون خرابی؛
- نداشتن قطعه یدکی و دستورالعمل برای نیروی مستقر؛
- نادیده گرفتن هزینه و زمان خروج از دیتاسنتر.
سؤالات متداول درباره خدمات کولوکیشن دیتاسنتر
آیا کولوکیشن شامل مدیریت سرور می‌شود؟
به‌طور خودکار خیر. دامنه مدیریت سیستم‌عامل، امنیت، بکاپ و نرم‌افزار باید در قرارداد یا سرویس مدیریت‌شده جداگانه مشخص شود.
آیا SLA صددرصدی یعنی هیچ قطعی رخ نمی‌دهد؟
خیر. چنین عبارتی یک تعهد با دامنه و شرایط قراردادی است، نه اثبات ناممکن بودن خرابی. تعریف نقض، استثناها و جبران خدمت را بررسی کنید.
برای شروع، یونیت بهتر است یا رک کامل؟
به تعداد تجهیزات، توان، نیاز دسترسی و رشد بستگی دارد. ممکن است توان موردنیاز پیش از فضای فیزیکی محدودکننده شود؛ فقط تعداد یونیت را مبنا نگیرید.
آیا دو مسیر برق برای دسترس‌پذیری بالا کافی است؟
خیر. استقلال مسیر، ظرفیت باقی‌مانده، اتصال صحیح تجهیزات و شبکه نیز اهمیت دارند. افزونگی نرم‌افزار و داده باید جدا طراحی شود.
چه مدارکی برای مقایسه دیتاسنترها لازم است؟
پیشنهاد فنی و مالی هم‌سطح، متن SLA، مشخصات نقطه تحویل، دامنه گواهی‌ها، جدول مسئولیت و برنامه پذیرش را درخواست کنید.
جمع‌بندی: انتخاب کولوکیشن با تعهد قابل سنجش
انتخاب مناسب خدمات کولوکیشن دیتاسنتر از تطبیق نیاز کسب‌وکار با ظرفیت واقعی، مسئولیت روشن و عملکرد قابل‌اندازه‌گیری شروع می‌شود. فضای رک، برق، شبکه و پشتیبانی را یک مجموعه وابسته به هم ببینید و کیفیت سرویس کاربر را جدا از سلامت تأسیسات بسنجید.
برای بررسی گزینه‌های استقرار، صفحه خدمات اجاره فضای رک آوابرید را ببینید. برای دریافت پیشنهاد متناسب، فهرست تجهیزات، مصرف برق، ظرفیت شبکه و نیاز رشد خود را از طریق تماس با آوابرید ارسال کنید و مشخصات فنی و SLA همان پیشنهاد را پیش از تصمیم نهایی دریافت کنید.