Single tenant vs multi-tenant network architecture advisor
Compare single-tenant dedicated hardware against multi-tenant shared fabric architectures. Model tenant capacity, hardware capital expense, radio airtime contention, and compliance isolation across commercial multi-unit environments.
Multi-family residential buildings where residents connect consumer IoT, Apple AirPlay, and smart speakers on a shared physical AP fabric requiring personal area network (PAN) isolation.
Recommended: Single SSID with Dynamic VLAN micro-segmentation per tenant
Private PSK assigns each tenant a distinct cryptographic key, steering all their devices into an isolated VLAN with Layer 2 Station Isolation. Zero lateral movement risk.
Consolidating all tenants onto 1 single broadcast SSID with Private PSK uses only 2.5% beacon overhead, preserving 97.5% airtime for high-speed client data.
| Evaluation Dimension | Multi-Tenant Shared + iPSK | Multi-Tenant 802.1X | Single-Tenant Dedicated |
|---|---|---|---|
| Hardware CapEx | Lowest (65-75% savings via pooled APs) | Low (shared physical fabric) | Highest (independent APs & routers per unit) |
| RF Spectrum Efficiency | Optimal (1 SSID, 2.5% beacon overhead) | Optimal (1 SSID, 2.5% beacon overhead) | Poor (co-channel interference across walls) |
| Consumer IoT Support | Native (smart TVs, consoles, AirPlay in PAN) | Requires MAC Authentication Bypass (MAB) | Native (isolated inside per-unit LAN) |
| Tenant Boundary Isolation | 802.1Q VLAN + Layer 2 Station Isolation | RADIUS RFC 3580 Dynamic VLAN assignment | Physical air-gap / separate hardware |
| Onboarding Experience | Instant self-service portal or SMS key | SSO profile / EAP-TLS certificate install | Manual physical technician setup per unit |
| Building Roaming | Seamless 802.11r across entire property | Seamless 802.11r across entire property | Connection drops when leaving tenant unit |
Designing a multi-tenant network for your property or enterprise?
Purple integrates directly with Cisco Meraki, HPE Aruba, Ruckus, and UniFi to automate tenant onboarding, Private PSK provisioning, and zero-trust network isolation.
single tenant vs multi tenant च्या वादात सर्वात सामान्य सल्ला देखील सर्वात कमी उपयुक्त ठरतो: single tenant सुरक्षित आहे, multi tenant स्वस्त आहे, आणि निर्णय प्रोक्युअरमेंट स्कोरकार्डवर संपतो. हे फ्रेमिंग अशा इमारतींमध्ये अपयशी ठरते जिथे नेटवर्क डिझाइनचा सर्वात मोठा व्यावसायिक प्रभाव पडतो.
हॉटेल, विद्यार्थी निवास, बिल्ड टू रेंट ब्लॉक, हॉस्पिटल कॅम्पस किंवा फ्लेक्सिबल वर्कस्पेसमध्ये, महत्त्वाचा प्रश्न हा असतो की नेटवर्कच्या सीमारेषेवर कोणाचे नियंत्रण आहे. एक समर्पित प्लॅटफॉर्म देखील खराब पॉलिसीमुळे ट्रॅफिक लीक करू शकतो. जेव्हा ओळख, ऑथेंटिकेशन, राउटिंग आणि रिव्होकेशन योग्यरित्या डिझाइन केले जाते, तेव्हा एक सामायिक भौतिक फॅब्रिक प्रत्येक भाडेकरूचे रक्षण करू शकते. भाडेकरूंची संख्या हे केवळ एक लेबल आहे. सीमारेषेवरील नियंत्रण ही खरी आर्किटेक्चर आहे.
UK मधील गृहनिर्माण पुरावे हा फरक दुर्लक्षित करणे कठीण करतात. सरकारी विश्लेषणाने 459,262 डेव्हलपमेंट्स ओळखल्या आहेत ज्या मिश्र-मालकीच्या (mixed tenure) आहेत किंवा असू शकतात, ज्यामध्ये 3.33 दशलक्ष सोशल घरे (social dwellings) आहेत, जी अधिकृत गृहनिर्माण आकडेवारीमध्ये ओळखल्या गेलेल्या 4.21 दशलक्ष सोशल घरांच्या 79% च्या बरोबरीची आहे. तरीही सरासरी सोशल-टेनंट गुणोत्तर 80% होते, तर मध्यक (median) 97% होते, जे दर्शवते की डेव्हलपमेंट्समध्ये अनेक प्रकारची मालकी असू शकते तर ती एकाच प्रकारच्या वहिवाटीत मोठ्या प्रमाणावर केंद्रित राहू शकते. पर्पज-बिल्ट फ्लॅट्स हे ओळखल्या गेलेल्या मल्टि-ड्वेलिंग डेव्हलपमेंट्सच्या 54% चे प्रतिनिधित्व करतात, ज्यांचे मध्यक सोशल-टेनंट गुणोत्तर 91% होते, तर कन्व्हर्टेड फ्लॅट्ससाठी हे प्रमाण 50% होते. प्रॉपर्टीचे स्वरूप ऑपरेशनल बाउंड्रीची समस्या बदलते, केवळ टेनन्सी कॉन्ट्रॅक्ट नाही. (इंग्लिश सोशल हाउसिंगमधील मिश्र-भाडेकरारावर UK सरकारचे विश्लेषण)
सिंगल टेनंट विरुद्ध मल्टी टेनंट हा प्रश्न SaaS पेक्षाही मोठा का आहे
एंटरप्राइझ टीम्सना सहसा SaaS खरेदीवरून या चर्चेचा सामना करावा लागतो. ते समर्पित इन्स्टन्सेसची तुलना शेअर्ड ॲप्लिकेशन इन्फ्रास्ट्रक्चरशी करतात, आणि नंतर असा निष्कर्ष काढतात की हाच नियम एका प्रत्यक्ष इमारतीला देखील लागू होतो. पण तसे नाही. शेअर्ड प्रॉपर्टीजमध्ये, अधिक महत्त्वाचा प्रश्न हा आहे की ऑपरेटर एखाद्या रहिवासी, अतिथी, विभाग किंवा कंत्राटदाराला योग्य ॲक्सेस आणि पॉलिसी मर्यादेत ठेवू शकतो का.
सिंगल - टेनंट डिप्लॉयमेंट सहसा इंजिनिअर्सना अधिक चांगली भौतिक विभागणी देते. यामुळे ऑडिटची व्याप्ती, बदल नियंत्रण आणि फॉल्ट कंटेनमेंटमध्ये मदत होते. पण यामुळे ऑपरेशनल जोखीम दूर होत नाही. एक कमकुवत पॅच असलेला कंट्रोलर, कमकुवत ॲडमिनिस्ट्रेटर क्रेडेंशियल, चुकीचे कॉन्फिगर केलेले फायरवॉल नियम किंवा चुकीची व्याप्ती असलेली ऑथेंटिकेशन सर्व्हिस यामुळे समर्पित वातावरणाला देखील तितकाच धोका निर्माण होऊ शकतो जितका शेअर्ड वातावरणाला होतो.
मल्टी - टेनंट नेटवर्किंग एक वेगळी जबाबदारी तयार करते. ऑपरेटर ॲक्सेस पॉईंट्स, स्विचेस, कंट्रोलर्स, अपलिंक्स आणि बऱ्याचदा मॅनेजमेंट प्लेन शेअर करतो, आणि नंतर युजर्सना वेगळे करण्यासाठी लॉजिकल कंट्रोल्स वापरतो. ते कंट्रोल्स वायरलेस, ऑथेंटिकेशन, राउटिंग, DNS, मॉनिटरिंग आणि सपोर्ट लेयर्सवर काम करणे आवश्यक आहे. एखादा टेनंट केवळ वेगळा SSID किंवा स्प्लॅश पेज असल्यामुळे वेगळा (isolated) होत नाही.
व्यावहारिक सीमा ही SSID नाही. ती आयडेंटिटीपासून ऑथरायझेशन, ट्रॅफिक फॉरवर्डिंग, टेलिमेट्री आणि रेव्होकेशनपर्यंतची संपूर्ण साखळी आहे.
चाचणी करण्यासाठी तीन सीमा
आर्किटेक्चरकडे तीन स्वतंत्र प्रश्न म्हणून पहा:
- भौतिक मर्यादा: कोणते रेडिओ, स्विचेस, कंट्रोलर्स, सर्किट्स आणि अप्लायन्सेस शेअर केले आहेत?
- ओळख मर्यादा (Identity boundary): नेटवर्कला कसे कळते की कोणती व्यक्ती, डिव्हाइस, खोली, विभाग किंवा कंपनी कनेक्ट होत आहे?
- व्यवस्थापन मर्यादा: क्रेडेंशियल कोण तयार करू शकते, पॉलिसी कोण बदलू शकते, टेलिमेट्रीची तपासणी कोण करू शकते, ॲक्सेस मंजूर कोण करू शकते आणि तो रद्द कोण करू शकते?
हॉस्पिटॅलिटी आणि रेसिडेन्शियल नेटवर्क्समध्ये हा दृष्टिकोन महत्त्वाचा ठरतो कारण युजर्सना विक्रेत्याने या डिझाइनला क्लाउड-नेटिव्ह, शेअर्ड किंवा डेडिकेटेड म्हटले आहे की नाही याने फरक पडत नाही. त्यांचे डिव्हाइसेस सहज कनेक्ट व्हावेत आणि त्यांच्या शेजाऱ्यांचे डिव्हाइसेस वेगळे राहावेत अशी त्यांची अपेक्षा असते. स्टाफच्या डिरेक्टरी अकाउंट निष्क्रिय केल्यावर त्यांचा ॲक्सेस नाहीसा होईल अशी त्यांची अपेक्षा असते. ऑपरेटर्सना प्रत्येक खोलीसाठी किंवा रहिवाशासाठी स्वतंत्र इन्फ्रास्ट्रक्चर असण्याऐवजी एकच सपोर्ट वर्कफ्लो हवा असतो.
UK चे फायर-सेफ्टी धोरण एक उपयुक्त समांतर उदाहरण देते. फायर सेफ्टी ॲक्ट 2021 ने स्पष्ट केले की दोन किंवा अधिक डोमेस्टिक प्रिमायसेस असलेल्या मल्टि-ऑक्यूपाइड निवासी इमारतींमधील स्ट्रक्चर, बाहेरील भिंती, बाल्कनी आणि फ्लॅटच्या प्रवेशद्वाराच्या दरवाजांना फायर सेफ्टी ऑर्डर लागू होते. संबंधित नियम 23 जानेवारी 2023 रोजी लागू झाले, तर ऐतिहासिक HMO नियंत्रणे गंभीर आगीच्या घटनांनंतर विकसित केली गेली आणि मल्टि-ऑक्यूपाइड इमारतींसाठी एक स्वतंत्र जोखीम श्रेणी औपचारिक केली गेली. (UK government mixed-tenure research and fire-safety context)
नेटवर्क आर्किटेक्ट्ससाठी हा धडा अगदी स्पष्ट आहे. शेअर्ड ऑक्युपेशनसाठी स्पष्ट नियंत्रणे आवश्यक आहेत, परंतु त्याचे उत्तर प्रत्येक वेळी केवळ डेडिकेटेड हार्डवेअर असेल असे नाही. इमारतीची जोखीम, व्यावसायिक मॉडेल आणि ऑपरेटिंग क्षमतेशी जुळणारी एक स्पष्ट सीमा असणे महत्त्वाचे आहे.
Single Tenant आणि Multi Tenant आर्किटेक्चरचे स्पष्टीकरण
नेटवर्किंगमध्ये, single tenant म्हणजे एका संस्थेला किंवा वापरकर्त्याला एक समर्पित इन्फ्रास्ट्रक्चर स्टॅक किंवा समर्पित ऑपरेशनल इन्स्टन्स मिळतो. त्यामध्ये स्वतंत्र ऍक्सेस पॉईंट्स, कंट्रोलर्स, VLANs, ऑथेंटिकेशन रिल्म्स, मॉनिटरिंग आणि मॅनेजमेंट परवानग्या समाविष्ट असू शकतात. ही रचना सामायिक अवलंबित्वे मर्यादित करते, ज्यामुळे संस्था जेव्हा प्रत्येक एंडपॉईंट आणि पॉलिसी निर्णयाची मालकी घेते तेव्हा परिस्थिती हाताळणे सोपे होते.
एखादा हॉस्पिटल ट्रस्ट, डिफेन्स साईट किंवा कॉर्पोरेट कॅम्पस कोअर ट्रॅफिकसाठी हे मॉडेल निवडू शकतात कारण त्यांच्या अंतर्गत आयडेंटिटी, कंप्लायन्स आणि इन्सिडंट-रिस्पॉन्स प्रक्रियांसाठी अत्यंत नियंत्रित एस्टेटची आवश्यकता असते. डेडिकेटेड इन्फ्रास्ट्रक्चर बेसपोक रेडिओ प्लॅनिंग, असामान्य डिव्हाइस आवश्यकता आणि चेंज विंडोजला देखील सपोर्ट करू शकते ज्यांचे इतर असंबंधित टेनंट्ससोबत समन्वय साधणे कठीण असते.
Multi tenant नेटवर्किंग प्रत्येक संस्था, कुटुंब, खोली, विभाग किंवा सेवेनुसार लॉजिकल नियंत्रणे लागू करताना एक सामान्य फिजिकल फॅब्रिक वापरते. VLANs, VRFs, RADIUS गुणधर्म, ओळख-आधारित खाजगी प्री-शेअर्ड की, फायरवॉल पॉलिसी आणि पॉलिसी इंजिन प्रत्येक उपकरणाची नक्कल न करता स्वतंत्र ॲक्सेस संदर्भ तयार करू शकतात.
फिजिकल नेटवर्क शेअर केलेले असते. परंतु सुरक्षा संदर्भ आणि युजरचा अनुभव शेअर केलेला नसावा. एखादी हॉटेल साखळी सर्व मालमत्तांमध्ये एक केंद्रीय व्यवस्थापित प्लॅटफॉर्म चालवू शकते, तर स्टुडंट अकॉमॉडेशन प्रदाता प्रत्येक रहिवासी किंवा युनिटला स्वतंत्र पॉलिसी आणि क्रेडेंशियल संदर्भाशी मॅप करू शकतो.
थोडक्यात single tenant विरुद्ध multi tenant नेटवर्किंग
| परिमाण | सिंगल टेनंट (Single Tenant) | मल्टी टेनंट (Multi Tenant) |
|---|---|---|
| भौतिक अलगाव (Physical isolation) | समर्पित इन्फ्रास्ट्रक्चर किंवा ऑपरेशनल इन्स्टन्स | सामायिक स्विचेस, ॲक्सेस पॉईंट्स, कंट्रोलर्स किंवा सर्किट्स |
| तार्किक अलगाव (Logical isolation) | सामान्यतः सोपे कारण कमी टेनंट्स पर्यावरण सामायिक करतात | आवश्यक, जे ओळख, VLANs, VRFs, फायरवॉल नियम आणि पॉलिसीद्वारे लागू केले जाते |
| मॅनेजमेंट प्लेन | समर्पित किंवा एकाच संस्थेसाठी घट्टपणे मर्यादित | टेनंट-जागरूक प्रशासन आणि नियुक्त परवानग्यांसह केंद्रीकृत |
| खर्च प्रमाणन (Cost scaling) | प्रत्येक टेनंटमागे इन्फ्रास्ट्रक्चर आणि ऑपरेशनल कामाची पुनरावृत्ती होते | इन्फ्रास्ट्रक्चर सामायिक करते आणि व्यवस्थापन केंद्रित करते |
| विशिष्ट संदर्भ | नियमन केलेले एंटरप्राइझ, संरक्षण, आरोग्य सेवा कोर, समर्पित कॉर्पोरेट इस्टेट | आदरातिथ्य (Hospitality), विद्यार्थी गृहनिर्माण, BTR, व्यवस्थापित सेवा, सामायिक कार्यस्थळे |
| मुख्य अपयशाचा मार्ग (Main failure mode) | नक्कल केलेल्या इस्टेट्स एकमेकांपासून वेगळ्या होतात किंवा त्यांची देखभाल कमी होते | पॉलिसी किंवा ओळख त्रुटी अनेक टेनंट्सवर परिणाम करू शकते |
डिप्लॉयमेंट पॅटर्नची तुलना करणाऱ्या टीम्स या मल्टी-टेनंट WiFi आर्किटेक्चर मार्गदर्शिकेचा एक व्यावहारिक संदर्भ म्हणून वापर करू शकतात, परंतु तरीही प्रत्यक्ष इमारत आणि ऑपरेटिंग मॉडेलनुसार या डिझाइनची चाचणी करणे आवश्यक आहे.
निवड सुरक्षित आणि असुरक्षित यामधील नाही. तर अधिक ड्युप्लिकेशन असलेल्या फिजिकल सेपरेशन आणि अधिक डिझाइन व गव्हर्नन्सची मागणी असलेल्या लॉजिकल सेपरेशन यामधील आहे.
महत्त्वाच्या निकषांनुसार समोरासमोर तुलना
आर्किटेक्चरचा निर्णय इमारत आणि ऑपरेटिंग मॉडेलवर अवलंबून असतो, SaaS लेबलवर नाही. आरोग्य सेवा नेटवर्क, विद्यार्थी निवास, BTR मालमत्ता आणि हॉटेल हे सर्व एक उपयुक्तता म्हणून WiFi प्रदान करू शकतात, तरीही त्यांच्या स्वीकार्य अपयशाच्या मर्यादा, सपोर्टच्या जबाबदाऱ्या आणि ट्रॅफिक पॅटर्न वेगवेगळे असतात.
जेव्हा एखादी त्रुटी केवळ एका संस्थेच्या भौतिक मालमत्तेपुरतीच मर्यादित असणे आवश्यक असते, तेव्हा single tenant निवडा. सामायिक मेंटेनन्स विंडोचा ताळमेळ न घालता इंजिनियर्स कंट्रोलर, फायरवॉल किंवा ऑथेंटिकेशन सर्व्हिस बदलू शकतात. हा फायदा केवळ तेव्हाच टिकतो जेव्हा प्रत्येक समर्पित वातावरणाला योग्य पॅचिंग, मॉनिटरिंग, दस्तऐवजीकरण आणि रिकव्हरी चाचणी मिळते. समर्पित इन्फ्रास्ट्रक्चर नियंत्रण देते, स्वयंचलित लवचिकता नाही.
जेव्हा एका ऑपरेटरला अनेक रहिवासी किंवा मालमत्तांमध्ये पुनरावृत्ती करण्यायोग्य सेवा प्रदान करणे आवश्यक असते तेव्हा मल्टी टेनंट निवडा. सामायिक फॅब्रिक मानक धोरण, मध्यवर्ती मॉनिटरिंग आणि सुसंगत ऑनबोर्डिंगला समर्थन देते. त्यानंतर ऑपरेटरवर अधिक मोठी गव्हर्नन्स जबाबदारी असते: क्रेडेन्शियल्स, ट्रॅफिक, टेलीमेट्री आणि प्रशासकीय प्रवेश प्रत्येक टेनंटसाठी योग्यरित्या स्कोप्ड राहिला पाहिजे.
डिझाइन ठरवणारे पाच निकष
| निकष | सिंगल टेनंट (Single Tenant) | मल्टी टेनंट (Multi Tenant) | अँकर पॉईंट |
|---|---|---|---|
| अलगाव (Isolation) | भौतिक अलगाव सामायिक ब्लास्ट रेडियस मर्यादित करते | तार्किक अलगाव प्रत्येक नियंत्रण स्तरावर असणे आवश्यक आहे | सामायिक स्कीमापासून ते डेटाबेस-पर-टेनंटपर्यंत, अलगावच्या तीव्रतेनुसार सुरक्षिततेची ताकद वाढते |
| सुरक्षा | कमी सामायिक अवलंबित्वामुळे स्पष्ट ऑडिट सीमा तयार होते | केंद्रीय नियंत्रणे सुसंगतता सुधारतात, परंतु एका पॉलिसीमधील त्रुटी अनेक टेनंट्सवर परिणाम करू शकते | सुरक्षा ही आर्किटेक्चर लेबल ऐवजी ओळख हमी, कॉन्फिगरेशन, पॅचिंग आणि मॉनिटरिंगचे अनुसरण करते |
| खर्च | प्रत्येक टेनंटसाठी हार्डवेअर, परवाने, सपोर्ट पाथ आणि देखभाल पुन्हा पुन्हा करावी लागते | सामायिक इन्फ्रास्ट्रक्चरचा वापर सुधारतो आणि वारंवार होणारे काम कमी करतो | अलगाव जसा वाढतो तसा प्रति-टेनंट खर्च वाढतो. सविस्तर खर्च तुलना पुढील विभागात दिसते (UK SaaS architecture comparison) |
| कामगिरी (Performance) | समर्पित क्षमता टेनंट्समधील संघर्ष टाळते | सामायिक क्षमतेसाठी प्रवेश नियंत्रण, QoS आणि सक्रिय देखरेख आवश्यक आहे | ऑपरेटरला गोंगाट करणारे शेजारी आणि उच्च मागणी असलेल्या उपकरणांसाठी स्पष्ट नियंत्रणे आवश्यक आहेत |
| ऑपरेशन्स | प्रत्येक पर्यावरण सोपे असू शकते, परंतु संपूर्ण रचना पुनरावृत्ती स्वरूपाची बनते | ओळख आणि पॉलिसी ऑटोमेशन प्रगत असल्यास एक प्लॅटफॉर्म कार्यक्षमतेने चालू शकतो | सिंगल टेनंट ऑपरेशनल काम प्रति पर्यावरण केंद्रित करते. मल्टी टेनंट ते प्रशासन आणि नियंत्रण प्लेनमध्ये केंद्रित करते |
आयसोलेशन हा एक डिझाइनचा गुणधर्म आहे
ट्रॅफिक प्रवाहाद्वारे आयसोलेशनची चाचणी घ्या, आकृत्यांद्वारे नाही. एक रहिवासी दुसऱ्या रहिवाशाचे डिव्हाइस शोधू शकतो का? एखादा पाहुणा कर्मचारी सेवांपर्यंत पोहोचू शकतो का? एखादा सपोर्ट ॲडमिनिस्ट्रेटर दुसऱ्या भाडेकरूचा सेशन डेटा पाहू शकतो का? डीप्रोविझन केलेल्या ओळखीचा ॲक्सेस त्वरित संपुष्टात येतो का, ज्यामध्ये आधी अधिकृत केलेल्या डिव्हाइसेसचाही समावेश आहे?
या दोन्ही मॉडेल्सना समान चाचण्या लागू होतात. समर्पित कंट्रोलर त्यांचे उत्तर स्वयंचलितपणे देत नाही आणि शेअर केलेला कंट्रोलर त्यांना अशक्य बनवत नाही. निर्णायक मुद्दा हा आहे की सुरक्षा नियम कुठे लागू केले जातात, ॲडमिनिस्ट्रेटर्सची व्याप्ती कशी ठरवली जाते आणि प्रत्येक भाडेकरूच्या खाली किती कॉमन इन्फ्रास्ट्रक्चर आहे.
विद्यार्थी गृहनिर्माण आणि BTR मध्ये, इमारतीमध्ये स्विचिंग, वायरलेस आणि अपस्ट्रीम कनेक्टिव्हिटी सामायिक केलेली असली तरीही रहिवासी खाजगी ॲक्सेसची अपेक्षा करतात. हॉटेल्सना पाहुणे, कर्मचारी आणि ऑपरेशनल सेवांमध्ये समान सीमांचा सामना करावा लागतो. आरोग्य सेवा व्यवस्थापित क्लिनिकल उपकरणे आणि जुन्या सिस्टीम जोडते, त्यामुळे पॉलिसी मॉडेलने नियमित सपोर्टला त्रासदायक न बनवता त्या अवलंबनांचे रक्षण केले पाहिजे.
कार्यप्रदर्शन मागणीच्या पद्धतीनुसार चालते
हॉटेल्समध्ये चेक-इन, इव्हेंट्स आणि संध्याकाळच्या वापराच्या वेळी केंद्रित मागणी दिसून येते. विद्यार्थ्यांच्या निवासांमध्ये उपकरणांची दाटी आणि सततचे बदल एकत्र पाहायला मिळतात. आरोग्य सेवेमध्ये व्यवस्थापित उपकरणे, वैयक्तिक उपकरणे आणि तज्ञ प्रणालींचे मिश्रण असते. Single tenant क्षमता राखून ठेवू शकतो, तर जेव्हा ऑपरेटर एअरटाइमचे मोजमाप करतो, QoS लागू करतो आणि मनोरंजक वापरापासून गंभीर ट्रॅफिक वेगळे करतो तेव्हा multi tenant हीच मागणी पूर्ण करू शकतो.
या प्रॉपर्टीजमध्ये आता WiFi ही एक जीवनावश्यक सुविधा आहे. सेवा खंडित झाल्यास त्याचा परिणाम केवळ टेक्निकल डॅशबोर्डवर होत नाही, तर रहिवाशांच्या अनुभवावर, अतिथींच्या कामांवर आणि व्यावसायिक परिणामांवर होतो.
व्यावहारिक चाचणी सोपी आहे: ऑपरेटर युजर्सनी तक्रार करण्यापूर्वी नेटवर्कमधील अडथळे शोधू शकतो का, जबाबदार टेनंट किंवा सर्व्हिस ओळखू शकतो का आणि नेटवर्कची पुनर्रचना न करता पॉलिसी बदलू शकतो का? तसे नसल्यास, निवडलेले आयसोलेशन मॉडेल अपूर्ण आहे.
खर्च, प्रमाण आणि आयसोलेशनचा लपलेला अतिरिक्त खर्च
समर्पित पायाभूत सुविधा प्रोजेक्ट प्लॅनमध्ये सोप्या दिसतात. प्रत्येक भाडेकरूला स्वतःचे नियंत्रक, स्विचेस, ॲक्सेस पॉइंट्स, परवाने, मॉनिटरिंग इंटिग्रेशन्स, ओळख स्टोअर्स, फर्मवेअर शेड्युल आणि सपोर्ट प्रक्रिया मिळते. या बिलामध्ये प्रत्येक कॉपी तैनात, दस्तऐवजीकरण, चाचणी, पॅच आणि रिकव्हर करण्यासाठी आवश्यक असलेला इंजिनिअरिंगचा वेळ समाविष्ट असतो.
सिंगल-टेनंट डिझाइनमुळे ऑपरेशनल कामाची पुनरावृत्ती देखील होते. इंजिनिअर्स स्वतंत्र टेम्पलेट्स मेंटेन करतात, वेगवेगळ्या कन्सोलमध्ये समान अलर्ट्सचे पुनरावलोकन करतात, फर्मवेअर व्हॅलिडेशनची पुनरावृत्ती करतात आणि स्वतंत्र रिकव्हरी प्रोसिजर्स सुरक्षित ठेवतात. जेव्हा एखाद्या टेनंटला विशिष्ट कंप्लायन्स बाउंड्री किंवा असामान्य टेक्निकल कंट्रोल्सची आवश्यकता असते, तेव्हा हा खर्च योग्य ठरतो. परंतु जेव्हा प्रत्येक टेनंटला समान सेवा मिळते आणि कोणत्याही पॉलिसीसाठी फिजिकल पृथक्करणाची आवश्यकता नसते, तेव्हा यामुळे नफ्याचे नुकसान होते.
आधीची खर्च तुलना अद्याप लागू होते, परंतु नेटवर्क ऑपरेटर्सना अशा खर्चाचा हिशोब ठेवावा लागतो जो SaaS कोष्टकांमध्ये दिसत नाही. स्वतंत्र कंट्रोलर लायसन्सची स्वतःची स्वतंत्र कंत्राटी व्याप्ती असू शकते. प्रत्येक अतिरिक्त प्लॅटफॉर्मसाठी डिप्लॉयमेंटपूर्वी सपोर्ट एग्रीमेंट, मेंटेनन्स विंडो आणि फर्मवेअर व्हॅलिडेशनची आवश्यकता असू शकते. इंजिनिअर्सना मल्टिपल एन्व्हायरनमेंट्समध्ये ऑथेंटिकेशन, मॉनिटरिंग, फेलओव्हर आणि टेनंट हँडऑफची चाचणी घेण्यात वेळ घालवावा लागतो. व्यस्त UK student housing, BTR किंवा हॉस्पिटॅलिटी पोर्टफोलिओमध्ये, हे तास थेट हार्डवेअरप्रमाणेच सर्व्हिस मार्जिनवर परिणाम करतात.
प्रति-टेनंट खर्च तपशील
| खर्च लाईन आयटम | सिंगल टेनंट, प्रति टेनंट | मल्टी टेनंट, प्रति टेनंट | टीपा |
|---|---|---|---|
| भौतिक पायाभूत सुविधा | समर्पित किंवा आरक्षित स्टॅक | सामायिक फॅब्रिक वाटप | सिंगल टेनंट उपकरणांची आणि साइटच्या कामाची पुनरावृत्ती करते |
| कंट्रोलर आणि प्लॅटफॉर्म परवाना | स्वतंत्र इन्स्टन्स किंवा परवाना व्याप्ती | सामायिक प्लॅटफॉर्म, टेनंट-जागरूक परवाना | कराराच्या अटी निकाल बदलू शकतात |
| ओळख आणि प्रमाणीकरण | स्वतंत्र क्षेत्र किंवा समर्पित एकत्रीकरण | स्कोप्ड धोरणांसह सामायिक सेवा | मल्टी टेनंटला मजबूत टेनंट मॅपिंगची आवश्यकता असते |
| मॉनिटरिंग | स्वतंत्र डॅशबोर्ड आणि अलर्ट मार्ग | टेनंट फिल्टरसह मध्यवर्ती डॅशबोर्ड | कमकुवत फिल्टरिंग प्रवेश-नियंत्रण जोखीम निर्माण करू शकते |
| समर्थन आणि बदल व्यवस्थापन | टेनंट-विशिष्ट विंडो आणि रनबुक | अपवादांसह प्रमाणित वर्कफ्लो | धोरण परिपक्व झाल्यावरच मानकीकरण स्केल सुधारते |
| पुनर्प्राप्ती आणि चाचणी | स्वतंत्र पुनर्प्राप्ती योजना | सामायिक प्लॅटफॉर्म पुनर्प्राप्ती अधिक टेनंट प्रमाणीकरण | ऑपरेटरने टेनंट-स्तरीय पुनर्संचयित करणे सिद्ध केले पाहिजे |
सामायिक प्लॅटफॉर्म केवळ तेव्हाच डुप्लिकेशन कमी करतो जेव्हा ऑपरेटर भाडेकरूच्या सीमा सातत्यपूर्णपणे लागू करू शकतो. यासाठी पॉलिसी टेम्पलेट्स, टप्प्याटप्प्याने उपयोजन, कॉन्फिगरेशन प्रमाणीकरण, भाडेकरू-लहान कक्षेतील लॉग आणि चाचणी केलेले रोलबॅक आवश्यक आहे. त्या नियंत्रणांशिवाय, एक सामायिक कन्सोल आयसोलेशनच्या समस्येला ॲक्सेस-कंट्रोलच्या समस्येत बदलू शकतो.
उत्पादन बदलांपूर्वी नेटवर्क डिझाइनची चाचणी घेतली पाहिजे. ओळख-आधारित वर्गीकरण मॉडेल करण्यासाठी, सबनेट वाटप तपासण्यासाठी आणि ॲड्रेस किंवा पॉलिसीमधील संघर्ष आधीच समोर आणण्यासाठी टीम्स iPSK subnet designer चा वापर करू शकतात.
जेव्हा व्यवसायाला फिजिकल सीमेची आवश्यकता असते तेव्हाच फिजिकल आयसोलेशनसाठी खर्च करा. डिझाइन टीमने एक विश्वासार्ह लॉजिकल सीमा तयार केली नाही म्हणून केवळ त्यासाठी विनाकारण खर्च करू नका.
योग्य उत्तर बरेचदा हायब्रिड असते. क्लिनिकल, पेमेंट, बिल्डिंग-मॅनेजमेंट किंवा कॉर्पोरेट ट्रॅफिक अत्यंत नियंत्रित समर्पित मार्गावर ठेवा. पाहुणे, रहिवासी, कंत्राटदार आणि इतर बदलत्या लोकांसाठी सामायिक, भाडेकरू-जागरूक नेटवर्क वापरा. हे वाटप अशा ठिकाणी अलगाव प्रदान करते जिथे बिघाड झाल्यास व्यावसायिक, नियामक किंवा सुरक्षिततेचे परिणाम होऊ शकतात, तर सामायिक इन्फ्रास्ट्रक्चर अशा मागण्या हाताळते ज्यांना स्केलचा फायदा होतो.
एंटरप्राइझ IT आणि नेटवर्क ऑपरेटर्ससाठी प्रत्यक्ष जगातील परिस्थिती
मालक, युजर आणि बिघाडामुळे होणारा परिणाम निश्चित केल्यावर आर्किटेक्चरचा निर्णय अधिक स्पष्ट होतो. एका संस्थेसाठी असलेले नेटवर्क म्हणजे ती केवळ सिंगल-टेनंट समस्या नसते आणि अनेक लोकांना सेवा देणारे नेटवर्क म्हणजे ती केवळ मल्टी-टेनंट समस्या नसते.
परिस्थिती १, एक ५,००० आसनांचा एंटरप्राइझ कॅम्पस
डेटा-रेसिडेन्सीच्या कडक आवश्यकता असलेल्या मोठ्या एंटरप्राइझ कॅम्पससाठी कोअर सर्व्हिसेसकरिता सिंगल टेनंट डिफॉल्ट असायला हवे. निर्णायक घटक हा युजर्सची संख्या नसून, फिजिकल, ॲडमिनिस्ट्रेटिव्ह आणि ऑडिट सीमा एकमेकांशी जुळवणे हा आहे.
समर्पित कंट्रोलर्स, ऑथेंटिकेशन सेवा, व्यवस्थापन ॲक्सेस आणि ट्रॅफिक पाथ्स मालकी सिद्ध करणे सोपे करतात. सुरक्षा टीम्स ॲडमिनिस्ट्रेटरचा ॲक्सेस संस्थेच्या कर्मचाऱ्यांपुरता मर्यादित करू शकतात, एकच बदल प्रक्रिया परिभाषित करू शकतात आणि असंबंधित भाडेकरूंच्या हालचाली फिल्टर न करता घटनांचा तपास करू शकतात.
गेस्ट ॲक्सेस अजूनही स्वतंत्र लॉजिकल सर्व्हिस वापरू शकतो. मुख्य कर्मचारी नेटवर्क तात्पुरते अभ्यागत, कंत्राटदार किंवा कार्यक्रमाला उपस्थित राहणाऱ्या लोकांसारख्याच पॉलिसी पाथवर अवलंबून नसावे.
परिस्थिती २, मल्टि-साइट हॉस्पिटॅलिटी ग्रुप
एका ब्रँडच्या अंतर्गत मालमत्ता चालवणाऱ्या हॉस्पिटॅलिटी ग्रुपने सामान्यतः multi tenant पर्याय निवडला पाहिजे. एका मध्यवर्ती नेटवर्क ऑपरेशन्स सेंटरला हॉटेल्स, रेस्टॉरंट्स आणि ठिकाणांवर सातत्यपूर्ण ऑनबोर्डिंग, captive portal पॉलिसी, रिपोर्टिंग आणि घटना प्रतिसाद आवश्यक असतो. प्रत्येक मालमत्तेवर संपूर्ण व्यवस्थापन इस्टेटची नक्कल केल्याने मानकीकरण कठीण होईल, सुरक्षित नाही.
सीमा अजूनही मालमत्ता, अतिथी, कर्मचारी आणि सेवा पातळीवर असणे आवश्यक आहे. अतिथींची उपकरणे पॉइंट-ऑफ-सेल सिस्टीमपर्यंत पोहोचू नयेत. कर्मचाऱ्यांच्या ओळखींना अतिथींच्या परवानग्या मिळू नयेत. मालमत्ता व्यवस्थापन टीमला त्यांच्या कामासाठी आवश्यक असलेली माहिती प्रत्येक साइटचा अनिर्बंध ॲक्सेस न मिळता दिसली पाहिजे.
यामधील तडजोड स्पष्ट आहे. ऑपरेटर टेनंट-अवेअर ॲडमिनिस्ट्रेशन आणि ट्रॅफिक पॉलिसी लागू करू शकत असल्यास सेंट्रलाइज्ड कंट्रोलचा विजय होतो.
परिस्थिती ३, UK BTR आणि विद्यार्थी गृहनिर्माण
बिल्ड-टू-रेंट आणि विशेष हेतूने तयार केलेल्या स्टुडंट अकॉमॉडेशनमध्ये, सामान्यतः हायब्रिड multi-tenant मॉडेल यशस्वी ठरते. रहिवाशांना अपार्टमेंट-पातळीवर किंवा खोली-पातळीवर गोपनीयतेची अपेक्षा असते, परंतु ऑपरेटरला संपूर्ण मालमत्तेत एकच फिजिकल नेटवर्क, एकच सपोर्ट मॉडेल आणि केंद्रीकृत सेवा व्यवस्थापनाचा फायदा होतो.
UK student housing evidence दर्शवते की स्कॉटलंडमधील सर्वेक्षण केलेल्या ९३% घरमालक सिंगल टेनन्सी एग्रीमेंट वापरतात, तर ७% मल्टिपल टेनन्सी एग्रीमेंट्स वापरतात. हे सूचित करते की प्रशासकीय सुलभता अजूनही ऑपरेटिंग मॉडेल्सवर प्रभाव पाडते. (UK student housing evidence)
या इमारतींमध्ये कनेक्टिव्हिटी ही प्रत्येक रहिवाशाने स्वतः केलेला करार न राहता, वाढत्या प्रमाणात ऑपरेटरने पुरवलेली सुविधा बनत आहे. Save the Student च्या National Student Accommodation Survey 2026 मध्ये, ८०% विद्यार्थ्यांनी सांगितले की त्यांच्या भाड्यात किमान एक अतिरिक्त सेवा समाविष्ट होती, आणि ४८% नी सांगितले की ब्रॉडबँड त्यात समाविष्ट होते — याच्या पुढे फक्त पाणी (६३%), वीज (६१%) आणि गॅस (५४%) होते. ते विश्वासार्हपणे पुरवणे हा अधिक कठीण भाग आहे: Jisc च्या २०२४/२५ सर्वेक्षणात, ज्यात UK मधील १५,३९८ उच्च शिक्षण विद्यार्थी सहभागी होते, ६०% नी कॅम्पसमध्ये किंवा बाहेर WiFi कनेक्टिव्हिटीच्या समस्या नोंदवल्या. (Save the Student, National Student Accommodation Survey 2026; Jisc Digital Experience Insights 2024/25)
त्यामुळे प्रत्येक रहिवाशाला स्वतंत्र इन्फ्रास्ट्रक्चर प्रोजेक्ट न बनवता नेटवर्कने एक खाजगी अनुभव देणे आवश्यक आहे. आर्किटेक्चर लेबलपेक्षा आयडेंटिटी-बेस्ड ॲक्सेस, प्रति-युनिट पॉलिसी, सोपे बिलिंग आणि त्वरित रेव्होकेशन अधिक महत्त्वाचे ठरतात.
नेटवर्कची डुप्लिकेट कॉपी न करता टेनंट आयसोलेशन देणे
आधुनिक ओळख-चालित नेटवर्किंग प्रत्येक भाडेकरूसाठी एक स्वतंत्र फिजिकल स्टॅक आणि अनियंत्रित सामायिक नेटवर्क या दरम्यान तिसरा पर्याय प्रदान करते. ऑपरेटर फॅब्रिक सामायिक करतो, नंतर ॲक्सेस एका व्यक्ती, युनिट, खोली, विभाग किंवा उपकरणाच्या ओळखीशी जोडतो.
निवासी आणि मिश्र-डिव्हाइस वातावरणासाठी iPSK हा एक व्यावहारिक सुरवातीचा बिंदू आहे. संपूर्ण इमारतीला एक सामायिक पासवर्ड देण्याऐवजी, ऑपरेटर वेगवेगळ्या खाजगी की नियुक्त करतो आणि त्यांना पॉलिसी संदर्भाशी मॅप करतो. ऑपरेशनल गरजेनुसार, एक की फ्लॅट, रूम, रहिवासी, डिव्हाइस ग्रुप किंवा सेवा वर्ग ओळखू शकते.
कंट्रोल प्लेन थरांमध्ये तयार करा
- ओळख आणि ॲक्सेस मॅप करा. युझर किंवा डिव्हाइसला योग्य टेनंट पॉलिसीशी जोडण्यासाठी RADIUS ॲट्रिब्युट्स, डिरेक्टरी ग्रुप्स किंवा मॅनेज्ड आयडेंटिटी सर्व्हिस वापरा.
- रोल-बेस्ड कंट्रोल्स लागू करा. कर्मचारी, रहिवासी, पाहुणे, कंत्राटदार आणि बिल्डिंग सिस्टम्सना वेगवेगळे अधिकार मिळाले पाहिजेत. या लेयरचे मूल्यांकन करणाऱ्या टीम्स रोलनुसार पॉलिसीच्या अधिक सविस्तर माहितीसाठी role based access control software चे पुनरावलोकन करू शकतात.
- ट्रॅफिक वेगळे करा. टेनंट्समधील लॅटरल मूव्हमेंट रोखण्यासाठी आणि ऑपरेशनल सिस्टम्सचे संरक्षण करण्यासाठी VLANs, VRFs, फायरवॉल नियम आणि सर्व्हिस पॉलिसी वापरा.
- लाइफसायकल इव्हेंट्स स्वयंचलित करा. जेव्हा रहिवासी किंवा कर्मचाऱ्याला मंजुरी मिळते तेव्हा ॲक्सेस प्रोव्हिजन करा आणि डिरेक्टरी किंवा प्रॉपर्टी-मॅनेजमेंट रेकॉर्ड बदलल्यावर तो रद्द करा.
- टेलिमेट्रीची व्याप्ती ठरवा. केंद्रीय मॉनिटरिंगने ऑपरेटर्सना उपयुक्त हेल्थ डेटा दिला पाहिजे, ज्यामुळे एका टेनंटची ओळख किंवा सेशनची माहिती दुसऱ्या टेनंटला उघड होणार नाही.
Entra ID किंवा Okta द्वारे SSO कॉर्पोरेट ॲक्सेसला स्थापित आयडेंटिटी गव्हर्नन्सशी जोडू शकते. हे कर्मचारी आणि व्यवस्थापित युजर्ससाठी चांगल्या प्रकारे कार्य करते. रहिवासी, अभ्यागत, जुनी डिव्हाइसेस आणि मॉडर्न एंटरप्राइझ ऑथेंटिकेशन फ्लो पूर्ण करू न शकणाऱ्या उपकरणांसाठी iPSK उपयुक्त ठरते.
Purple चे identity-based networking platform हे कंट्रोल-प्लेन दृष्टिकोनाचे एक उदाहरण आहे जे सामायिक इन्फ्रास्ट्रक्चरवर टेनंट-विशिष्ट ॲक्सेसचे समर्थन करते, ज्यामध्ये iPSK आणि एंटरप्राइझ आयडेंटिटी प्रोव्हाइडर्ससह इंटिग्रेशन्सचा समावेश आहे. या आर्किटेक्चरमधील त्याचे मूल्य आणखी एक SSID असणे हे नाही. तर प्रत्येक रहिवाशासाठी स्वतंत्र फिजिकल नेटवर्कची आवश्यकता नसताना आयडेंटिटी, पॉलिसी, ऑनबोर्डिंग आणि रिव्होकेशन कनेक्ट करण्याची क्षमता हे आहे.
डिझाईनला अजूनही टेस्टिंगची गरज आहे. एखादा क्रेडेंशियल त्याच्या ठरवून दिलेल्या पॉलिसीचे उल्लंघन करत नाही, डिव्हाइस ऑनबोर्डिंग सेगमेंटेशनला बायपास करत नाही, ॲडमिनिस्ट्रेटर्सकडे टेनंट - स्कोप्ड परवानग्या आहेत आणि ॲक्सेस रद्द करण्याचे काम ॲक्टिव्ह सेशन्सपर्यंत पोहोचते, याची पडताळणी करा. एक शेअर्ड फिजिकल नेटवर्क खाजगी टेनंटचा अनुभव देऊ शकते, परंतु केवळ तेव्हाच जेव्हा ऑपरेटर ओळख आणि पॉलिसीकडे प्रॉडक्शन इन्फ्रास्ट्रक्चर म्हणून पाहतो.
तुम्ही कोणते आर्किटेक्चर कधी निवडले पाहिजे
जेव्हा संस्थेला केवळ स्वतंत्र लॉगिन नव्हे, तर समर्पित भौतिक सीमारेषेची आवश्यकता असते तेव्हा single tenant चा वापर करा. नियमन केलेले आरोग्य सेवा, पेमेंटचे वातावरण, संरक्षण आणि अत्यंत संवेदनशील एंटरप्राइझ कामांसाठी कोर सर्व्हिसेससाठी येथूनच सुरुवात केली पाहिजे. हे आर्किटेक्चर पुरावे गोळा करणे सोपे करते आणि सामायिक अवलंबित्व कमी करते, जरी यासाठी शिस्तबद्ध पॅचिंग, मॉनिटरिंग आणि ओळख व्यवस्थापनाची आवश्यकता असते.
जेव्हा ऑपरेटर अनेक ग्राहक, रहिवासी, खोल्या, विभाग किंवा प्रॉपर्टीजची सेवा करत असतो आणि सेवा ही सातत्यपूर्ण डिलिव्हरीवर अवलंबून असते, तेव्हा मल्टी टेनंटचा वापर करा. हॉस्पिटॅलिटी, स्टुडंट हाऊसिंग, BTR, मॅनेज्ड सर्व्हिसेस आणि शेअर्ड वर्कस्पेसना सहसा हार्डवेअरची डुप्लिकेट कॉपी तयार करण्यापेक्षा सेंट्रलाइज्ड ऑपरेशन्सचा जास्त फायदा होतो. यासाठी कडक टेनंट - अवेअर पॉलिसी असणे आवश्यक आहे, सुरक्षेचा सैल दर्जा नाही.
जेव्हा एकाच साइटवर उच्च संवेदनशीलता असलेल्या अंतर्गत सेवा आणि मोठ्या प्रमाणात तात्पुरते किंवा निवासी युजर्स दोन्ही असतात, तेव्हा हायब्रिड वापरा.
आर्किटेक्चर शिफारस मॅट्रिक्स
| प्रसंग | शिफारस केलेले मॉडेल | कारण |
|---|---|---|
| नियमन केलेले एंटरप्राइझ कोअर, आरोग्यसेवा क्लिनिकल प्रणाली, किंवा पेमेंट ट्रॅफिक | सिंगल टेनंट (Single tenant) | भौतिक आणि ऑडिट सीमा संस्थेच्या नियंत्रण सीमेशी जुळली पाहिजे |
| अनेक ग्राहकांना सेवा देणारा SaaS प्रदाता किंवा व्यवस्थापित सेवा ऑपरेटर | मल्टी टेनंट (Multi tenant) | सामायिक पायाभूत सुविधा पुनरावृत्ती करण्यायोग्य धोरण, मध्यवर्ती ऑपरेशन्स आणि कार्यक्षम विस्तारास समर्थन देतात |
| मध्यवर्ती अतिथी सेवांसह हॉटेल समूह | मल्टी टेनंट (Multi tenant) | एक ऑपरेटिंग मॉडेल सर्व मालमत्तांमध्ये सुसंगत ओळख, समर्थन आणि सेवा वितरणास समर्थन देते |
| BTR, विद्यार्थी गृहनिर्माण, किंवा लवचिक कार्यस्थान | हायब्रिड मल्टी टेनंट (Hybrid multi tenant) | सामायिक पायाभूत सुविधा प्रति-रहिवासी ओळख, धोरण, बिलिंग आणि निरसन यासह कार्य करतात |
| कर्मचारी आणि अतिथी नेटवर्कसह कॉर्पोरेट साइट | हायब्रिड (Hybrid) | टेनंट-जागरूक अतिथी प्रवेश लागू करताना संवेदनशील कॉर्पोरेट ट्रॅफिक घट्ट नियंत्रित ठेवा |
| सतत होणाऱ्या गोंगाट-शेजारी (noisy-neighbour) घटना किंवा ऑडिट निष्कर्षांसह पर्यावरण | पुनर्मूल्यांकन करा, नंतर प्रभावित सेवा अलग करा | आर्किटेक्चर लेबल काहीही असले तरी, वर्तमान सीमा अपयशी ठरत आहे |
मायग्रेशनचे निर्णय याच तर्कावर आधारित असले पाहिजेत. प्लॅटफॉर्म निवडण्यापूर्वी ट्रॅफिक क्लासेस, ओळखी (identities), डिव्हाइस प्रकार, व्यवस्थापन भूमिका आणि फेल्युअर डोमेन्सची यादी तयार करा. अस्पष्ट क्रॉस - टेनंट व्हिजिबिलिटी, साईट्समधील विसंगत पॉलिसी, ॲक्सेस रद्द होण्यास होणारा उशीर, मर्यादेपेक्षा जास्त ॲडमिनिस्ट्रेटिव्ह अधिकार असलेल्या सपोर्ट टीम्स आणि नियंत्रण नसणे किंवा वैशिष्ट्यांच्या विलंबाने टेनंट सोडून जाणे, ही धोक्याची लक्षणे आहेत.
डिझाइनवर स्वाक्षरी करण्यापूर्वी एक प्रश्न विचारा: नेटवर्क सीमेचा मालक कोण आहे, आणि त्यांना समर्पित हार्डवेअरची आवश्यकता आहे की समर्पित पॉलिसीची?
मार्गदर्शक दस्तऐवजाचा सारांश अगदी सोपा आहे:
- जेव्हा फिजिकल आयसोलेशन ही व्यवसाय किंवा अनुपालनाची आवश्यकता असते तेव्हा single tenant निवडा.
- जेव्हा स्केलेबिलिटी सामायिक पायाभूत सुविधा आणि परिपक्व ओळख नियंत्रणांवर अवलंबून असते तेव्हा multi tenant निवडा.
- जेव्हा संवेदनशील मुख्य ट्रॅफिक आणि हाय-व्हॉल्यूम सामायिक ॲक्सेस एकाच वेळी अस्तित्त्वात असतात तेव्हा हायब्रिड निवडा.
Purple सामायिक इमारतींसाठी ओळख-आधारित नेटवर्किंग प्रदान करते, ज्यामध्ये सामान्य इन्फ्रास्ट्रक्चरवर भाडेकरू-पातळीवरील ऍक्सेस नियंत्रणे आणि iPSK-आधारित पृथक्करण समाविष्ट आहे. हा दृष्टिकोन तुमच्या विद्यार्थ्यांचे गृहनिर्माण, BTR, आदरातिथ्य, आरोग्य सेवा किंवा एंटरप्राइझ गेस्ट-नेटवर्क डिझाइनला अनुकूल आहे की नाही हे तपासण्यासाठी Purple ला भेट द्या, आणि नंतर तुमच्या स्वतःच्या ओळख, रिव्होकेशन आणि ट्रॅफिक पॉलिसीसह सीमारेषेची चाचणी घ्या.
