در قسمت دوم، روش‌های راه‌اندازی بروکر اختصاصی روی تجهیزات محلی و سرور اجاره‌ای را بررسی کردیم. اما همه پروژه‌ها به نصب و اداره مستقیم نرم‌افزار بروکر نیاز ندارند. گاهی اجاره یک سرویس آماده، زمان راه‌اندازی را کوتاه می‌کند؛ گاهی نیز نیاز اصلی پروژه، مجموعه‌ای از امکانات شامل ذخیره داده، داشبورد و هشدار است که یک پلتفرم اینترنت اشیا آن‌ها را یکجا فراهم می‌کند.
در این قسمت، انتخاب میان این روش‌ها را از دید بهره‌برداری واقعی بررسی می‌کنیم: چه چیزی می‌خریم، چه مسئولیتی بر عهده ما باقی می‌ماند و هنگام قطع ارتباط یا خرابی سرویس چه باید کرد؟ محور بحث همچنان خود بروکر و جایگاه آن در سامانه است.
تصویر آغاز مقاله ـ ارتباط ابری میان گلخانه، کارخانه و ساختمان
۱. اجاره بروکر ابری چگونه است؟
سرویس اشتراکی، بدون‌سرور و نمونه اختصاصی
در اجاره بروکر ابری، به‌جای نصب نرم‌افزار روی یک سرور خام، معمولاً حسابی در سامانه ارائه‌دهنده ایجاد می‌کنیم. سپس نشانی اتصال، اطلاعات احراز هویت و امکاناتی برای تنظیم دسترسی‌ها دریافت می‌کنیم. اجرای زیرساخت و بخشی از نگهداری، مطابق قرارداد، بر عهده ارائه‌دهنده است.
در سرویس اشتراکی، چند مشتری از زیرساخت یا خوشه مشترک استفاده می‌کنند، ولی حساب‌ها و مجوزهای آن‌ها باید از یکدیگر جدا باشد. اشتراکی‌بودن به معنی عمومی‌بودن پیام‌ها نیست؛ کیفیت جداسازی و محدودیت منابع، بخشی از مشخصات فنی خدمت است.
در سرویس بدون‌سرور، مشتری درگیر انتخاب و اداره سرور نیست و هزینه معمولاً با مصرف ارتباط دارد. این نام به معنی نبودن سرور یا رایگان‌بودن ارتباط دائمی نیست. برای نمونه، در سرویس بدون‌سرور ای‌ام‌کیوایکس، زمان اتصال نشست‌ها و ترافیک از عوامل محاسبه هزینه هستند. در نمونه اختصاصی، محیط بروکر برای مشتری جدا می‌شود؛ اما این موضوع لزوماً به معنی اختصاص تمام سخت‌افزار فیزیکی نیست.
EMQX Cloud
تفاوت بروکر عمومی آزمایشی با سرویس ابری دارای حساب خصوصی
بروکر عمومی آزمایشی معمولاً برای یادگیری، بررسی یک کتابخانه یا آزمایش کوتاه ارتباط در دسترس است. اگر کاربران ناشناس بتوانند روی موضوع‌های مشترک منتشر کنند یا مشترک شوند، دانستن نام موضوع می‌تواند برای مشاهده یا ایجاد پیام کافی باشد. انتخاب نام طولانی و تصادفی برای موضوع، جای کنترل دسترسی را نمی‌گیرد.
در مقابل، یک سرویس رایگان دارای حساب خصوصی ممکن است احراز هویت و مجوزهای جداگانه داشته باشد. بنابراین، «رایگان»، «عمومی» و «اشتراکی» سه مفهوم متفاوت‌اند. رمزگذاری ارتباط نیز به‌تنهایی تعیین نمی‌کند چه کسی حق دریافت یا ارسال پیام دارد.
گردانندگان بروکر آزمایشی مسکویتو صریحاً توصیه می‌کنند داده حساس در آن منتشر نشود و برای کاربرد مهم به آن اتکا نشود. این سرویس برای آزمون مفید است، اما محل مناسبی برای فرمان واقعی پمپ، درِ ورودی یا تجهیزات تولید نیست.
محدودیت‌ها و شیوه محاسبه هزینه
پیش از خرید، سقف اتصال هم‌زمان، نرخ پیام، اندازه پیام، حجم ترافیک، طول صف و محدودیت نگهداری نشست بررسی می‌شود. عبور از سقف ممکن است به افزایش هزینه، محدودشدن ارسال یا رد اتصال منجر شود؛ رفتار دقیق به طرح بستگی دارد.
برای یک مثال فرضی، صد دستگاه که در تمام یک ماه سی‌روزه متصل بمانند، چهار میلیون و سیصد و بیست هزار دقیقه اتصال ایجاد می‌کنند. این عدد فقط زمان اتصال را نشان می‌دهد؛ تعداد پیام‌ها و ترافیک را باید جدا حساب کرد. همچنین پیامی که به ده مشترک تحویل می‌شود، می‌تواند ترافیک خروجی بیشتری از همان پیام با یک گیرنده بسازد.
طرح‌های مختلف ممکن است بر اساس زمان سرویس، ظرفیت رزروشده، تعداد پیام یا ترافیک قیمت‌گذاری شوند. سهمیه رایگان نیز معمولاً سقف دارد. برآورد هزینه باید با یک الگوی مصرف واقعی و با درنظرگرفتن رشد تعداد دستگاه‌ها انجام شود، نه صرفاً قیمت آغازین روی صفحه فروش.
شکل ۱ ـ تقسیم مسئولیت میان ارائه‌دهنده سرویس ابری و تیم پروژه
۲. معرفی سرویس‌های بروکر ابری ایرانی و خارجی
نمونه‌های رایگان و پولی
در نمونه‌های خارجی، ای‌ام‌کیوایکس کلاد مدل‌های بدون‌سرور و اختصاصی را عرضه می‌کند. بدون‌سرور می‌تواند برای شروع با مصرف محدود مناسب باشد؛ نمونه اختصاصی برای نیاز به جداسازی و ظرفیت مشخص قابل بررسی است. انتخاب نهایی به محدودیت‌ها، منطقه استقرار و شرایط دسترسی مشتری بستگی دارد.
هایوام‌کیو کلاد نیز سرویس مدیریت‌شده ارائه می‌کند، اما نباید معرفی‌های قدیمی طرح رایگان آن را بدون بررسی تکرار کرد. طبق اعلام رسمی در زمان نگارش، ایجاد خوشه جدید در طرح قدیمی بدون‌سرور متوقف شده و پایان فعالیت خوشه‌های موجود برای ۳۱ دسامبر ۲۰۲۶ اعلام شده است. طرح استارتر مسیر دیگری با دوره آزمایشی و شرایط پرداخت خودش دارد. این تغییر نمونه روشنی از ضرورت بازبینی خدمات ابری در طول عمر پروژه است.
HiveMQ Cloud
در ایران، چابکان و رانفلر خدمات میزبانی آماده مسکویتو را معرفی کرده‌اند. این‌ها نمونه‌هایی برای تهیه محیط آماده اجرای بروکر هستند؛ نباید بدون بررسی قرارداد، آن‌ها را معادل تمام امکانات یک بروکر ابری کاملاً مدیریت‌شده دانست. وضعیت داده پایدار، نسخه پشتیبان، تمدید گواهی و مسئولیت به‌روزرسانی باید در طرح انتخابی روشن شود.
خدمات مناسب آزمایش، پروژه کوچک و کاربرد صنعتی
برای آموزش، یک بروکر عمومی آزمایشی با داده ساختگی می‌تواند کافی باشد. برای یک پروژه کوچک واقعی، حساب خصوصی با دسترسی محدود و امکان پشتیبان‌گیری یا انتقال، اهمیت بیشتری دارد. رایگان‌بودن مفید است، ولی جای پاسخ‌گویی در زمان خرابی را نمی‌گیرد.
در کاربرد صنعتی، معیار انتخاب باید مدت قابل تحمل توقف، امکان ادامه کار محلی، تعهد پشتیبانی و فرایند بازیابی باشد. اختصاصی‌بودن نمونه به‌تنهایی این نیازها را برآورده نمی‌کند. یک نمونه اختصاصی تک‌گرهی نیز ممکن است با خرابی همان گره از دسترس خارج شود.
مقایسه ظرفیت، امکانات، پشتیبانی و دسترسی
| نوع خدمت | کاربرد قابل بررسی | نکته تعیین‌کننده |
| بروکر عمومی آزمایشی | یادگیری و آزمون کوتاه | بدون داده حساس و بدون اتکای عملیاتی |
| بروکر ابری با حساب خصوصی | پروژه کوچک تا مقیاس بزرگ، بسته به طرح | سقف مصرف، مجوزها و تعهد خدمت |
| میزبانی آماده مسکویتو | استقرار سریع یک محیط بروکر | تفکیک مسئولیت میزبان و مدیر نرم‌افزار |
| نمونه مدیریت‌شده اختصاصی | نیاز به جداسازی یا ظرفیت مشخص | معماری پایداری، قرارداد و هزینه |
هنگام مقایسه دو سرویس، عدد «تعداد اتصال» را کنار نرخ مجاز پیام و ترافیک قرار دهید. پشتیبانی عمومی تیکتی با رسیدگی قراردادی به اختلال حیاتی یکسان نیست. کیفیت دسترسی نیز باید از شبکه واقعی دستگاه، مثلاً سیم‌کارت نصب‌شده در گلخانه، سنجیده شود.
اطلاعات خدمات در این مقاله بر پایه منابع رسمیِ بررسی‌شده در ۱۳ اکتبر ۲۰۲۶ است. ظرفیت، تعرفه و شرایط طرح‌ها ممکن است تغییر کند؛ به همین دلیل جدول بالا مقایسه نوع خدمت است، نه فهرست قیمت ثابت.
۳. استفاده از پلتفرم اینترنت اشیا به‌جای تهیه بروکر مستقل
پلتفرم چه امکاناتی فراتر از بروکر ارائه می‌دهد؟
بروکر، پیام را دریافت و بر اساس اشتراک‌ها و مجوزها توزیع می‌کند. برای تبدیل این ارتباط به محصول نهایی، معمولاً به بخش‌های دیگری نیاز داریم: ثبت تاریخچه، تعریف دستگاه، نمایش نمودار، مدیریت کاربران و اجرای قواعد هشدار. پلتفرم اینترنت اشیا مجموعه‌ای از این امکانات را کنار هم قرار می‌دهد.
وقتی از پلتفرم استفاده می‌کنیم، لزوماً بروکر از معماری حذف نمی‌شود؛ ممکن است قابلیت دریافت پیام یا یک بروکر درون آن وجود داشته باشد و مدیریت مستقیمش به کاربر واگذار نشود. در برخی معماری‌ها نیز پلتفرم به بروکر مستقل پروژه متصل می‌شود. پشتیبانی از این اتصال به محصول و نسخه آن بستگی دارد.
داشبورد، ذخیره‌سازی، هشدار و مدیریت دستگاه‌ها
در یک گلخانه، بروکر می‌تواند پیام دما را به برنامه‌های مجاز برساند. برای نمایش نمودار هفتگی، باید داده در یک سامانه ذخیره شود. برای اعلام دمای غیرعادی، قاعده تشخیص و مسیر ارسال هشدار لازم است. برای محدودکردن دسترسی کاربران هر گلخانه نیز سازوکار مدیریت کاربر نیاز داریم.
پلتفرمی مانند تینگزبورد قابلیت‌هایی در زمینه جمع‌آوری و نمایش داده، مدیریت دستگاه و پردازش رویداد ارائه می‌کند. البته امکانات دقیق میان نسخه‌ها و شیوه استقرار یکسان نیست. داشتن پنل مدیریتی در یک بروکر نیز به معنی داشتن داشبورد کاربردی و تاریخچه کامل داده‌های تجهیزات نیست.
ThingsBoard
شکل ۲ ـ تفاوت دامنه امکانات بروکر و پلتفرم اینترنت اشیا
تفاوت پلتفرم خودمیزبان با پلتفرم ابری
در پلتفرم خودمیزبان، نرم‌افزار روی زیرساخت در اختیار مجموعه اجرا می‌شود. کنترل بیشتری بر محل داده و تنظیمات داریم، ولی مسئولیت نگهداری پایگاه داده، فضای ذخیره‌سازی، سرویس‌های جانبی و به‌روزرسانی‌ها نیز افزایش می‌یابد. اداره یک پلتفرم کامل معمولاً از اداره یک بروکر ساده گسترده‌تر است.
در پلتفرم ابری، بخش بیشتری از زیرساخت آماده است و راه‌اندازی داشبورد می‌تواند سریع‌تر باشد. در عوض، باید هزینه تعداد دستگاه‌ها، حجم داده، مدت نگهداری تاریخچه و دسترسی به رابط برنامه‌نویسی را بررسی کرد. امکان خروجی‌گرفتن از داده و انتقال تنظیمات نیز پیش از خرید اهمیت دارد.
نمونه‌های ایرانی و خارجی و محدودیت سازگاری آن‌ها
در ایران، تینگزپاد خدمات ابری و استقرار محلی را معرفی می‌کند و امکاناتی مانند داشبورد، مدیریت دستگاه و قواعد پردازشی دارد. پشتیبانی از ام‌کیوتی‌تی در آن به معنی ضرورت بررسی قالب پیام و روش شناسایی دستگاه مطابق مستندات پلتفرم است.
پاپلی نیز در معرفی پلتفرم خود، اتصال تجهیزات، داشبورد، هشدار و گزینه‌های استقرار ابری، خصوصی یا داخل سازمان را توضیح می‌دهد. برای تطبیق با پروژه، باید نسخه قابل تحویل، محل میزبانی، تعرفه و مسیر اتصال سخت‌افزار از ارائه‌دهنده استعلام شود؛ صفحه معرفی به‌تنهایی جای آزمون عملی را نمی‌گیرد.
در نمونه‌های خارجی، تینگزبورد برای ترکیب دریافت داده، مدیریت و داشبورد قابل بررسی است. سرویس اینترنت اشیای آمازون نیز امکانات اتصال امن، مدیریت ارتباط و هدایت داده به خدمات دیگر فراهم می‌کند؛ اما نباید آن را معادل یک داشبورد نهایی آماده برای هر کاربرد دانست. ساخت محصول کامل ممکن است به اجزای دیگری نیاز داشته باشد.
AWS IoT Core
نکته مهم این است که هر سامانه دارای پشتیبانی ام‌کیوتی‌تی، یک بروکر عمومی با آزادی کامل در موضوع‌ها نیست. برای نمونه، مستندات مایکروسافت محدودیت‌های ارتباط ام‌کیوتی‌تی در آی‌اوتی هاب و قراردادهای مشخص موضوع را توضیح می‌دهد. در پلتفرم‌ها ممکن است نام موضوع، ساختار پیام و اطلاعات ورود از پیش تعیین شده باشد. پیش از انتخاب، یک ارسال داده و یک دریافت فرمان با همان دستگاه واقعی آزمایش کنید.
Azure IoT Hub
۴. کدام روش برای پروژه ما مناسب‌تر است؟
مقایسه بروکر محلی، سرور اجاره‌ای، بروکر ابری و پلتفرم
بهترین گزینه، روشی است که نیاز ارتباطی و توان نگهداری پروژه را هم‌زمان پوشش دهد. خرید امکانات زیاد بدون فرد مسئول بهره‌برداری، لزوماً پایداری ایجاد نمی‌کند. از طرف دیگر، ساده‌ترین استقرار نیز ممکن است هزینه توسعه داشبورد و ثبت داده را به تیم تحمیل کند.
| روش | مزیت اصلی | مسئولیت مهم پروژه |
| بروکر محلی | ارتباط نزدیک تجهیزات و امکان کار محلی | برق، سخت‌افزار، نسخه پشتیبان و دسترسی دور |
| بروکر روی سرور اجاره‌ای | اختیار نصب و تنظیمات | اداره سیستم‌عامل و نرم‌افزار |
| بروکر ابری مدیریت‌شده | کاهش امور اجرایی زیرساخت | مجوزها، مصرف و سازگاری دستگاه‌ها |
| پلتفرم اینترنت اشیا | امکانات آماده برای داده و کاربر | طراحی کاربرد، قواعد و امکان مهاجرت |
انتخاب برای آموزش، خانه هوشمند، گلخانه و صنعت
برای آموزش، مسکویتو روی رایانه یا حساب آزمایشی خصوصی، مشاهده رفتار بروکر را آسان می‌کند. در خانه هوشمند، اگر کنترل روزمره باید هنگام قطع اینترنت ادامه یابد، معماری محلی با دسترسی ابری تکمیلی ارزش بررسی دارد.
در گلخانه، تصمیم مهم این است که آبیاری یا تهویه چقدر به اینترنت وابسته باشد. پایش از راه دور می‌تواند ابری باشد، در حالی که منطق ضروری کنترل در محل اجرا شود. در صنعت، حساسیت توقف، نیاز به ثبت رویداد و الزامات شبکه سازمان تعیین می‌کند بروکر کجا قرار بگیرد و چه پشتیبانی لازم داشته باشد.
این مثال‌ها نسخه ثابت برای همه پروژه‌ها نیستند. یک گلخانه کوچک با کنترل دستیِ پشتیبان با مجموعه‌ای که تجهیزات حیاتی‌اش فقط فرمان اینترنتی می‌گیرند، نیاز یکسانی ندارد.
برآورد هزینه واقعی مالکیت و بهره‌برداری
هزینه واقعی از جمع مجوز یا اشتراک، زیرساخت، ترافیک، ذخیره‌سازی، توسعه نرم‌افزار، نیروی نگهداری و پیامد توقف به دست می‌آید. در استقرار محلی، برق و تعویض ذخیره‌ساز را باید دید؛ در سرویس ابری، رشد مصرف و هزینه خروجی داده مهم است.
برای مقایسه منصفانه، یک بازه مشخص، مثلاً یک سال، در نظر بگیرید و هزینه راه‌اندازی را از هزینه ماهانه جدا کنید. سپس سناریوی رشد تعداد دستگاه‌ها و افزایش دریافت‌کنندگان پیام را نیز محاسبه کنید. بروکر رایگان ممکن است با احتساب وقت نگهداری گران‌تر تمام شود؛ پلتفرم پولی نیز ممکن است با حذف بخشی از توسعه اختصاصی به‌صرفه باشد.
۵. چالش‌های ارتباطی و دسترسی
قطع اینترنت و ناپایداری شبکه موبایل
در اتصال سیم‌کارتی، تغییر کیفیت پوشش و قطع کوتاه ارتباط عادی است. دستگاه باید اتصال مجدد با فاصله‌گذاری مناسب داشته باشد تا بازگشت هم‌زمان تعداد زیادی دستگاه، بار ناگهانی ایجاد نکند. همچنین لازم است مشخص شود داده‌های تولیدشده در زمان قطعی کجا نگهداری می‌شوند.
بروکر ابری نمی‌تواند داده‌ای را که هرگز به آن نرسیده بازیابی کند. اگر حفظ داده لازم است، دستگاه یا گیت‌وی به بافر با ظرفیت و سیاست حذف مشخص نیاز دارد. زمان اندازه‌گیری باید همراه داده ذخیره شود تا داده دیررس با اندازه‌گیری تازه اشتباه نشود.
محدودیت دسترسی به خدمات خارجی
پیش از وابسته‌کردن محصول به یک سرویس خارجی، امکان ایجاد حساب، پرداخت، دریافت پشتیبانی و استفاده از مناطق میزبانی بررسی شود. شرایط ارائه خدمت و دسترسی شبکه می‌تواند تغییر کند. موفقیت آزمایش روی اینترنت دفتر، تضمین دسترسی تمام مشتریان از همه اپراتورها نیست.
آدرس بروکر و اطلاعات اتصال را تا حد امکان قابل تنظیم نگه دارید. اگر تغییر سرویس مستلزم مراجعه حضوری به هزار دستگاه باشد، هزینه و زمان مهاجرت بسیار بیشتر خواهد شد.
تأخیر، پهنای باند و هزینه ترافیک
برای پایش روند دما، تأخیر چندثانیه‌ای ممکن است پذیرفتنی باشد؛ برای یک حلقه کنترل سریع، همان تأخیر مناسب نیست. معیار باید زمان رفت‌وبرگشت تا برنامه و تجهیز واقعی باشد، نه فقط پاسخ شبکه سرور.
ارسال بی‌وقفه مقادیر تکراری می‌تواند مصرف سیم‌کارت و هزینه سرویس را افزایش دهد. انتخاب دوره نمونه‌برداری، ارسال هنگام تغییر معنادار و ارسال دوره‌ای وضعیت سلامت باید متناسب با نیاز کاربرد انجام شود. کاهش ترافیک نباید باعث پنهان‌ماندن قطع دستگاه یا حذف رویداد مهم شود.
وابستگی به ارائه‌دهنده و امکان مهاجرت
استفاده از قالب‌های اختصاصی، قواعد پیچیده و داشبوردهای انحصاری می‌تواند مهاجرت را دشوار کند. مستندسازی موضوع‌ها، قالب پیام، مجوزها و ارتباط دستگاه‌ها کمک می‌کند هزینه تغییر سرویس قابل پیش‌بینی بماند.
پیش از خرید، امکان خروجی داده، انتقال تنظیمات و تغییر نشانی اتصال را بررسی کنید. همه اطلاعات، مانند رمزها، نشست‌ها یا قواعد پلتفرم، الزاماً قابل انتقال مستقیم نیستند. یک آزمایش کوچک انتقال، از فرض «بعداً به‌سادگی جابه‌جا می‌شویم» قابل اتکاتر است.
۶. امنیت در بهره‌برداری واقعی
حساب مستقل برای هر دستگاه
وقتی همه دستگاه‌ها از یک رمز استفاده می‌کنند، افشای همان رمز می‌تواند کل مجموعه را درگیر کند. هویت و اطلاعات ورود مستقل امکان قطع دسترسی یک دستگاه معیوب یا مفقود را بدون توقف دیگران فراهم می‌کند. شناسه کلاینت به‌تنهایی جای رمز، گواهی یا سازوکار احراز هویت را نمی‌گیرد.
حساب مدیر، برنامه داشبورد و دستگاه میدانی نیز باید از هم جدا باشند. اطلاعات مدیریتی را در نرم‌افزار دستگاه یا صفحه‌ای که برای کاربر نهایی ارسال می‌شود قرار ندهید.
محدودکردن دسترسی به موضوع‌ها
دستگاه هر سالن فقط باید اجازه انتشار داده و دریافت فرمان‌های مربوط به همان سالن را داشته باشد. برنامه ناظر نیز ممکن است صرفاً حق مشاهده داشته باشد. این مجوزها باید روی بروکر یا لایه کنترل دسترسی سرویس اعمال شوند؛ پنهان‌کردن یک دکمه در داشبورد کافی نیست.
آزمون امنیت فقط بررسی اتصال موفق نیست. لازم است با یک حساب محدود، انتشار یا دریافت غیرمجاز نیز امتحان شود و نتیجه آن ردشدن دسترسی باشد. قابلیت‌ها و شیوه تعریف مجوز در هر نرم‌افزار متفاوت است؛ مستندات مسکویتو یکی از نمونه‌های مرجع برای تنظیم احراز هویت و کنترل دسترسی است.
مدیریت رمزها و گواهی‌ها
برای ارتباط اینترنتی، رمزگذاری و بررسی معتبر هویت سرور اهمیت دارد. دستگاه باید زنجیره گواهی و زمان لازم برای اعتبارسنجی را درست مدیریت کند. پیش از انتخاب سرویس، سازگاری کتابخانه و سخت‌افزار واقعی با الزامات امنیتی آن آزمایش شود.
برای تمدید گواهی، تعویض رمز و ابطال دسترسی برنامه داشته باشید. در تعداد زیاد دستگاه، تعویض ناگهانی بدون دوره انتقال می‌تواند قطعی گسترده ایجاد کند. نسخه پشتیبان اطلاعات دسترسی نیز باید محافظت شود و رمزها در گزارش‌های معمول چاپ نشوند.
خطر استفاده عملیاتی از بروکرهای عمومی آزمایشی
بروکر عمومی می‌تواند در معرض پیام‌های کاربران ناشناس باشد و ممکن است بدون تعهد پایداری متوقف یا بازنشانی شود. حتی برای آزمایش، از شناسه واقعی مشتری، موقعیت دقیق تجهیزات یا فرمان متصل به عملگر استفاده نکنید. داده ساختگی و عملگر شبیه‌سازی‌شده برای چنین محیطی مناسب‌تر است.
۷. نگهداری، پایش و رفع خرابی
به‌روزرسانی نرم‌افزار و سیستم‌عامل
در استقرار خودمیزبان، به‌روزرسانی بروکر، سیستم‌عامل و وابستگی‌ها بر عهده تیم پروژه است. پیش از تغییر نسخه، یادداشت انتشار و سازگاری تنظیمات بررسی و در صورت امکان روی محیط آزمایش اجرا شود. نسخه پشتیبان و روش بازگشت باید پیش از شروع آماده باشند.
در سرویس مدیریت‌شده، بخشی از این کار به ارائه‌دهنده منتقل می‌شود؛ بااین‌حال، مشتری باید زمان نگهداری، تغییرات سازگاری و احتمال اتصال مجدد دستگاه‌ها را پیگیری کند. مدیریت‌شده‌بودن، مسئولیت آزمایش برنامه و تجهیزات را حذف نمی‌کند.
بررسی مصرف منابع، اتصال‌ها و گزارش خطا
تعداد اتصال‌های فعال، قطع و وصل غیرعادی، نرخ پیام، مصرف حافظه، صف‌های معطل و فضای دیسک شاخص‌های مفیدی هستند. تنها روشن‌بودن فرایند بروکر کافی نیست؛ یک آزمون دوره‌ای انتشار و دریافت از بیرون سرور، مسیر واقعی را بهتر نشان می‌دهد.
هنگام خرابی، مسیر را مرحله‌به‌مرحله بررسی کنید: آیا دستگاه روشن است؟ شبکه و نام دامنه کار می‌کنند؟ اتصال امن و ورود موفق است؟ مجوز موضوع درست است؟ برنامه دریافت‌کننده پیام را پردازش می‌کند؟ برای مثال، نرسیدن نمودار جدید ممکن است ناشی از توقف پایگاه داده باشد، در حالی که خود بروکر سالم است.
شکل ۳ ـ مسیر بررسی اختلال از دستگاه تا برنامه کاربردی
پشتیبان‌گیری و آزمایش بازیابی
نسخه پشتیبان می‌تواند تنظیمات، مجوزها، گواهی‌های لازم و داده‌های پایدار بروکر را شامل شود. تاریخچه اندازه‌گیری در پایگاه داده برنامه نیز معمولاً نسخه پشتیبان جدا می‌خواهد. کپی فایل‌ها باید با روش سازگار با نرم‌افزار و وضعیت اجرای آن انجام شود.
پشتیبان زمانی قابل اتکاست که بازیابی آن آزمایش شده باشد. یک محیط جدا ایجاد کنید، تنظیمات را برگردانید و اتصال، مجوزها و داده‌های مورد انتظار را بررسی کنید. مدت لازم برای بازیابی و بیشترین بازه قابل قبول از دست‌رفتن داده را نیز مشخص کنید.
انقضای گواهی، پرشدن دیسک و اختلال سرویس
بسیاری از قطعی‌ها از ایراد پیچیده پروتکل ناشی نمی‌شوند: گواهی منقضی می‌شود، گزارش‌ها دیسک را پر می‌کنند، اعتبار سرویس تمام می‌شود یا رمز یک دستگاه تغییر می‌کند. برای این موارد، هشدار پیشگیرانه و مسئول پاسخ‌گو تعیین کنید.
| نشانه | بررسی اولیه | اقدام پیشگیرانه |
| قطع هم‌زمان بسیاری از دستگاه‌ها | وضعیت سرویس، شبکه، گواهی و حساب | پایش بیرونی و هشدار پیش از انقضا |
| اتصال برقرار است ولی داده نمی‌رسد | مجوز، موضوع، صف و برنامه گیرنده | آزمون دوره‌ای مسیر کامل پیام |
| افزایش مصرف دیسک | گزارش‌ها، داده پایدار و صف‌ها | چرخش گزارش و هشدار ظرفیت |
| قطع مکرر یک دستگاه | تغذیه، پوشش شبکه و شناسه تکراری | ثبت علت قطع و آزمون در محل |
هشدار خرابی نباید فقط از همان سامانه‌ای عبور کند که خرابی‌اش را اعلام می‌کند. مسیر اطلاع‌رسانی مستقل و دستورالعمل کوتاه رسیدگی، زمان تشخیص را کاهش می‌دهد.
۸. افزایش پایداری و توسعه آینده
راه‌اندازی مجدد خودکار و سرویس جایگزین
اجرای خودکار پس از روشن‌شدن و راه‌اندازی مجدد پس از توقف برنامه، جلوی بخشی از قطعی‌های طولانی را می‌گیرد. اما تکرار بی‌پایان راه‌اندازی مجدد، مشکل تنظیمات نادرست یا پرشدن دیسک را حل نمی‌کند؛ علت توقف باید ثبت و بررسی شود.
سرویس جایگزین نیز زمانی مفید است که روش انتقال دستگاه‌ها، تنظیمات و داده‌های لازم مشخص باشد. تغییر دامنه به‌تنهایی اتصال‌های موجود را منتقل نمی‌کند و دستگاه‌ها به رفتار درست اتصال مجدد نیاز دارند. این فرایند باید پیش از خرابی واقعی تمرین شود.
خوشه‌بندی و دسترس‌پذیری بالا
خوشه‌بندی یعنی همکاری چند گره با سازوکار مشخص نرم‌افزار برای خدمت‌رسانی. قراردادن دو بروکر مستقل پشت یک توزیع‌کننده بار، خودبه‌خود نشست‌ها، اشتراک‌ها و پیام‌های آن‌ها را همگام نمی‌کند. قابلیت خوشه‌بندی، محدودیت نسخه و هزینه مجوز باید بررسی شود.
دسترس‌پذیری بالا علاوه بر نرم‌افزار، به محل استقرار گره‌ها، شبکه، ذخیره‌سازی و رفتار کلاینت‌ها وابسته است. اگر همه گره‌ها از یک منبع برق یا یک مسیر شبکه مشترک استفاده کنند، همان نقطه مشترک می‌تواند کل سرویس را متوقف کند.
ارتباط بروکر محلی و ابری
در معماری ترکیبی، یک بروکر محلی نزدیک تجهیزات کار می‌کند و داده‌های انتخابی به بروکر یا سرویس ابری منتقل می‌شوند. این انتقال می‌تواند با قابلیت پل‌زدن بروکر یا یک برنامه واسط انجام شود. مسکویتو از پیکربندی پل میان بروکرها پشتیبانی می‌کند.
باید موضوع‌های قابل انتقال، جهت هر مسیر، دسترسی‌ها و رفتار زمان قطعی مشخص باشد. انتقال بی‌قید همه موضوع‌ها در هر دو جهت می‌تواند باعث حلقه پیام یا تکرار ناخواسته شود. همچنین پل ارتباطی با خوشه‌بندی یکسان نیست؛ این دو، مسئله‌های متفاوتی را حل می‌کنند.
شکل ۴ ـ ترکیب ارتباط محلی و ابری با حفظ کنترل ضروری در محل
حفظ عملکرد محلی هنگام قطع اینترنت
برای ادامه کار محلی، فقط نصب بروکر کافی نیست. کنترلر، منطق تصمیم‌گیری و دسترسی‌های لازم نیز باید در محل قابل استفاده باشند. در مثال گلخانه، کنترل ضروری تهویه می‌تواند محلی باشد و ابر برای مشاهده، تحلیل و تنظیمات مجاز استفاده شود.
پس از بازگشت اینترنت، داده‌های بافرشده با زمان اصلی خود ارسال می‌شوند. فرمان‌های قدیمی نیز نباید بدون بررسی اجرا شوند؛ اعتبار زمانی، شناسه فرمان و گزارش نتیجه اجرا به جلوگیری از عمل تکراری یا دیرهنگام کمک می‌کند. توقف ارتباط با ابر باید یک وضعیت تعریف‌شده در طراحی باشد، نه اتفاقی که رفتار تجهیزات را نامعلوم می‌کند.
۹. چک‌لیست نهایی انتخاب و راه‌اندازی بروکر
پیش از تحویل پروژه، پاسخ این پرسش‌ها را ثبت و موارد مهم را با آزمایش تأیید کنید:
۱. کاربرد اصلی چیست: فقط تبادل پیام یا داشبورد، تاریخچه و هشدار نیز لازم است؟
۲. در زمان قطع اینترنت، کدام عملکردها باید در محل ادامه یابند؟
۳. تعداد دستگاه‌ها، نرخ پیام، اندازه پیام و تعداد گیرندگان مشخص شده‌اند؟
۴. نوع خدمت، سقف مصرف، روش محاسبه هزینه و مسئولیت نگهداری روشن است؟
۵. اتصال از سخت‌افزار، اپراتور و محل واقعی نصب آزمایش شده است؟
۶. هر دستگاه هویت مستقل و فقط دسترسی مورد نیاز خود را دارد؟
۷. ورود غیرمجاز، اشتراک غیرمجاز و انتشار فرمان غیرمجاز در آزمون رد می‌شوند؟
۸. رمزگذاری، اعتبارسنجی گواهی و برنامه تمدید یا تعویض اطلاعات ورود آماده است؟
۹. قطع شبکه، بازگشت هم‌زمان دستگاه‌ها و مدیریت داده دیررس آزمایش شده‌اند؟
۱۰. پایش، مسیر هشدار مستقل و فرد مسئول رسیدگی مشخص هستند؟
۱۱. نسخه پشتیبان بازیابی شده و مدت بازیابی اندازه‌گیری شده است؟
۱۲. انتقال به سرویس دیگر و تغییر تنظیمات دستگاه‌ها، مسیر عملی مشخصی دارد؟
انتخاب بروکر در عمل انتخاب شیوه اداره ارتباطات پروژه است. کیفیت این انتخاب زمانی روشن می‌شود که سامانه با رشد تعداد دستگاه‌ها، قطع اینترنت یا خرابی یک جزء روبه‌رو شود. سرویس مناسب باید هم در روز راه‌اندازی کار کند و هم برای نگهداری، بازیابی و تغییرات آینده برنامه‌ای قابل اجرا داشته باشد.
دیدگاه خود را بنویسید