[{"data":1,"prerenderedAt":209},["ShallowReactive",2],{"blog-opha-message-bus-multi-tenant-nmis":3},{"id":4,"title":5,"author":6,"body":7,"categories":186,"category":187,"date":188,"description":189,"extension":190,"featured":191,"fields":186,"image":192,"meta":193,"modified":186,"navigation":194,"path":195,"seo":196,"slug":197,"stem":198,"tags":199,"__hash__":208},"blog\u002Fblog\u002Fopha-message-bus-multi-tenant-nmis.md","How opHA and the opHA Message Bus Make Multi-Tenant NMIS Actually Work","FirstWave",{"type":8,"value":9,"toc":176},"minimark",[10,14,17,20,25,28,31,34,41,45,48,51,54,58,64,67,70,73,79,83,86,92,95,98,101,104,108,111,114,133,136,142,146,160,168],[11,12,13],"p",{},"Network management for one customer is a solved problem. Running NMIS on a single server, polling a few hundred devices, and watching one dashboard works fine.",[11,15,16],{},"Network management for a hundred customers is a different sport. Suddenly you need tenant isolation that actually holds, geographic distribution that does not melt your WAN, real-time visibility that survives a server outage, and one operations surface that your NOC can actually work from. Most architectures collapse somewhere along the way. Either tenants leak into each other, or operators end up with a wall of dashboards, or the platform falls over the first time a primary server reboots.",[11,18,19],{},"This is the problem opHA was built for, and it is the reason FirstWave introduced the opHA Message Bus as the next-generation architecture for distributed NMIS. If you run a managed service, a carrier network, an ISP, or a global enterprise, this post is for you.",[21,22,24],"h2",{"id":23},"what-opha-actually-is","What opHA Actually Is",[11,26,27],{},"opHA is the high availability and distributed-management product for NMIS. It coordinates multiple NMIS instances, primary servers and pollers, into one logical platform. Operators see a consolidated view, customers stay isolated, and the underlying infrastructure can sit in different data centres or regions without your team having to think about it.",[11,29,30],{},"There are two architectures inside the opHA family. Classic opHA uses a scheduled-pull model between pollers and the primary. It is the right choice for smaller distributed deployments where minute-level sync is fine. The opHA Message Bus is the newer architecture: a peer-to-peer message bus that streams events, configuration, and health data between primaries, pollers, and mirrors in real time.",[11,32,33],{},"For multi-tenant deployments, the message bus is the architecture that earns its keep.",[11,35,36],{},[37,38],"img",{"alt":39,"src":40},"Diagram showing opHA classic and Message Bus architectures side by side","\u002Fimages\u002Fblog\u002FophaMB-Draft.png",[21,42,44],{"id":43},"what-the-message-bus-changes","What the Message Bus Changes",[11,46,47],{},"A scheduled-sync architecture is fine until the gaps between syncs start to matter. The moment you have a customer asking why an event from a remote site took ninety seconds to land in the dashboard, or a regulator asking how you guarantee no events were lost during a failover, scheduled sync runs out of room.",[11,49,50],{},"The opHA Message Bus replaces that with a continuous stream. Every peer (primary, poller, or mirror) is connected to the bus. Events flow the instant they are generated. Configuration changes propagate as soon as they are committed. Daemon health is visible across the estate in real time. Messages are replicated across peers, so a server failure does not lose the events that were in flight.",[11,52,53],{},"The operational benefit is concrete. Mean time to repair drops because operators see what is happening as it happens, not on the next sync. SLA breaches caused by missed events stop happening because events are not missed. Failover stops being a manual incident-response exercise, because primary failover is automated and the bus carries the state forward.",[21,55,57],{"id":56},"what-it-looks-like-in-practice","What It Looks Like in Practice",[11,59,60],{},[37,61],{"alt":62,"src":63},"opHA Message Bus Home view showing peer cards and daemon health","\u002Fimages\u002Fblog\u002FopCharts_opha-message-bus-page.png",[11,65,66],{},"The opHA-MB Home view is the operational centre. Each peer card shows peer type, heartbeat, streaming state, node count, ophad health, and the live status of every NMIS daemon (opchartsd, opeventsd, opconfigd, nmis9d, omkd, ophad). In a small lab you might have two pollers and one mirror. In a real production deployment, you might have pollers in Chicago, San Francisco, and Frankfurt, each with a paired mirror in another region, each carrying one to two thousand nodes.",[11,68,69],{},"The point is that the screen does not change. The cards get smaller, the numbers get bigger, the geography spreads, and the operational model stays the same. Operators learn one view, and that view scales from a single rack to a global topology without retraining.",[11,71,72],{},"The same is true at the service layer. opHA Message Bus carries service-level state, not just device state. SSL expiry checks, port checks, application stack checks, anything NMIS or opCharts is tracking, all stream into one consolidated view. KPI cards summarise the global state at a glance. The table drills into individual checks. Operators triage from one place, click through to the source poller, and resolve faster.",[11,74,75],{},[37,76],{"alt":77,"src":78},"opEvents events streaming via opHA Message Bus","\u002Fimages\u002Fblog\u002FopEvents-op-ha-messagebus.png",[21,80,82],{"id":81},"why-this-matters-for-multi-tenant-deployments","Why This Matters For Multi-Tenant Deployments",[11,84,85],{},"Multi-tenancy is where the architecture decisions you made on day one come back to either help you or hurt you. The opHA Message Bus was designed for the multi-tenant case from the beginning, and it shows up in three places.",[11,87,88],{},[37,89],{"alt":90,"src":91},"opCharts consolidated view across multi-tenant opHA-MB deployment","\u002Fimages\u002Fblog\u002Fophamb-opcharts.png",[11,93,94],{},"First, tenant data stays separate end-to-end. Each tenant's nodes, events, and configuration are isolated at the data layer, not bolted on with filters that someone could disable. A poller can be dedicated to one customer, shared across customers with strict isolation, or run in a hybrid model where a few large customers get their own pollers and the long tail share. Operators see one consolidated view across every tenant. Customers only ever see their own data.",[11,96,97],{},"Second, you scale by adding peers, not by spinning up parallel NMIS stacks. Add a customer, add their pollers, point them at the message bus. Most MSPs do not want a separate NMIS stack per tenant, and with the message bus they do not need one. The architecture handles isolation without forcing the duplication.",[11,99,100],{},"Third, the operations surface stays single. One platform to operate, one platform to bill against. Per-tenant counts roll up into the same management views your operators already use. Onboarding a new customer becomes a poller-deployment exercise, not a platform-deployment exercise.",[11,102,103],{},"For carriers and ISPs, the same properties translate into carrier-grade distributed monitoring. Pollers in every PoP, mirrors in adjacent regions, real-time event streaming back to the NOC, and zero event loss across the lot. That is what the message bus delivers, and it is what scheduled-sync architectures cannot.",[21,105,107],{"id":106},"when-to-move-to-the-message-bus","When To Move To The Message Bus",[11,109,110],{},"If you are running classic opHA today and your deployment fits comfortably (a few hundred nodes, a single primary, sync latency that nobody is asking about), there is no urgency. Classic opHA continues to be supported and continues to be the right architecture for that size of deployment.",[11,112,113],{},"The signals that it is time to look at the message bus are familiar:",[115,116,117,121,124,127,130],"ul",{},[118,119,120],"li",{},"You are crossing the threshold where one primary cannot carry the load",[118,122,123],{},"You are adding a third or fourth geography and the WAN bandwidth bill is starting to hurt",[118,125,126],{},"A customer or regulator is asking you to prove zero event loss",[118,128,129],{},"Your operations team is spending real time on failover scenarios that could be automated",[118,131,132],{},"You are pitching multi-tenant monitoring as a service, and the answer to \"how is data isolated\" needs to be stronger than \"we filter by group\"",[11,134,135],{},"When any two of those are true, the message bus is the right move.",[11,137,138],{},[37,139],{"alt":140,"src":141},"Message bus decision graphic for distributed network monitoring","\u002Fimages\u002Fblog\u002FMessage-Bus-Blog-Graphic.png",[21,143,145],{"id":144},"where-to-go-next","Where To Go Next",[11,147,148,149,154,155,159],{},"The dedicated ",[150,151,153],"a",{"href":152},"\u002Fproducts\u002Fopha-message-bus\u002F","opHA Message Bus product page"," walks through the architecture, the screenshots, the specifications, and the multi-tenant model in more depth. The broader ",[150,156,158],{"href":157},"\u002Fproducts\u002Fopha\u002F","opHA page"," covers both architectures and helps you pick between them.",[11,161,162,163,167],{},"If you want to see the lab view and the production view side by side with one of our solution engineers, ",[150,164,166],{"href":165},"\u002Fdemo\u002F","book a demo",". It is the fastest way to understand what your deployment will actually look like.",[11,169,170,171,175],{},"opHA and the opHA Message Bus are part of the ",[150,172,174],{"href":173},"\u002Fproducts\u002Fnmis\u002F","NMIS 9"," platform from FirstWave. Built for the teams that cannot afford to miss a thing.",{"title":177,"searchDepth":178,"depth":178,"links":179},"",2,[180,181,182,183,184,185],{"id":23,"depth":178,"text":24},{"id":43,"depth":178,"text":44},{"id":56,"depth":178,"text":57},{"id":81,"depth":178,"text":82},{"id":106,"depth":178,"text":107},{"id":144,"depth":178,"text":145},null,"Network Management","2026-05-12","MSPs, telcos, and ISPs run thousands of devices across thousands of customer environments. Here is how opHA, and specifically the opHA Message Bus, give them one platform to manage all of it without sacrificing tenant isolation, real-time visibility, or fault tolerance.","md",false,"\u002Fimages\u002Fblog\u002Fopha-mb_diagram.png",{},true,"\u002Fblog\u002Fopha-message-bus-multi-tenant-nmis",{"title":5,"description":189},"opha-message-bus-multi-tenant-nmis","blog\u002Fopha-message-bus-multi-tenant-nmis",[200,201,202,203,204,205,206,207],"opHA","opHA Message Bus","NMIS","multi-tenant","MSP","telco","ISP","distributed monitoring","oPlVFwQjCdyCMTUb2OT-KDLT0DdArhh0ta-uIWf-rt4",1782795851604]