माइक्रोसर्भिस आर्किटेक्चरमा SSO। हामी किक्लोक प्रयोग गर्छौं। भाग नम्बर १

कुनै पनि ठूला कम्पनीमा, र X5 रिटेल समूह कुनै अपवाद छैन, किनकि यो विकसित हुन्छ, परियोजनाहरूको संख्या जसलाई प्रयोगकर्ता प्राधिकरण चाहिन्छ। समयको साथमा, प्रयोगकर्ताहरूको एक अनुप्रयोगबाट अर्कोमा सिमलेस ट्रान्जिसन आवश्यक छ, र त्यसपछि त्यहाँ एकल सिंगल-सिङ-अन (SSO) सर्भर प्रयोग गर्न आवश्यक छ। तर के हुन्छ जब पहिचान प्रदायकहरू जस्तै AD वा अन्य जसमा अतिरिक्त विशेषताहरू छैनन् विभिन्न परियोजनाहरूमा पहिले नै प्रयोग गरिन्छ। "पहिचान दलालहरू" भनिने प्रणालीहरूको एक वर्ग उद्धारमा आउनेछ। सबैभन्दा कार्यात्मक यसका प्रतिनिधिहरू हुन्, जस्तै कीक्लोक, ग्रेभिटी पहुँच व्यवस्थापन, इत्यादि। प्राय: प्रयोगका केसहरू फरक हुन सक्छन्: मेसिन अन्तरक्रिया, प्रयोगकर्ताको सहभागिता, इत्यादि। समाधानले लचिलो र स्केलेबल कार्यक्षमतालाई समर्थन गर्नुपर्छ जसले सबै आवश्यकताहरूलाई एकमा मिलाउन सक्छ, र त्यस्ता समाधानहरू हाम्रो कम्पनीसँग अब एक संकेत ब्रोकर छ - कीक्लोक।

Keycloak RedHat द्वारा राखिएको खुला स्रोत पहिचान र पहुँच नियन्त्रण उत्पादन हो। यो SSO - RH-SSO प्रयोग गरेर कम्पनीको उत्पादनहरूको लागि आधार हो।

आधारभूत अवधारणाहरू

तपाईंले समाधानहरू र दृष्टिकोणहरू बुझ्न सुरु गर्नु अघि, तपाईंले सर्तहरू र प्रक्रियाहरूको अनुक्रम परिभाषित गर्नुपर्छ:

पहिचान उसको पहिचानकर्ता द्वारा विषय पहिचान गर्ने प्रक्रिया हो (अर्को शब्दमा, यसले नाम, लगइन वा नम्बर निर्धारण गर्दैछ)।

प्रमाणीकरण - यो एक प्रमाणीकरण प्रक्रिया हो (प्रयोगकर्ता पासवर्ड प्रयोग गरी प्रमाणित गरिएको छ, पत्र एक इलेक्ट्रोनिक हस्ताक्षर प्रयोग गरी प्रमाणित गरिएको छ, आदि)।

प्राधिकरण - यो संसाधनमा पहुँचको प्रावधान हो (उदाहरणका लागि, इ-मेलमा)।

पहिचान ब्रोकर कीक्लोक

किक्लोक IS मा प्रयोगको लागि डिजाइन गरिएको खुला स्रोत पहिचान र पहुँच व्यवस्थापन समाधान हो जहाँ माइक्रोसर्भिस आर्किटेक्चर ढाँचाहरू प्रयोग गर्न सकिन्छ।

Keycloak ले एकल साइन-अन (SSO), दलाल पहिचान र सामाजिक लगइन, प्रयोगकर्ता संघ, ग्राहक एडेप्टर, प्रशासक कन्सोल र खाता व्यवस्थापन कन्सोल जस्ता सुविधाहरू प्रदान गर्दछ।

Keycloak द्वारा समर्थित आधारभूत कार्यक्षमता:

• ब्राउजर अनुप्रयोगहरूको लागि एकल-साइन अन र एकल-साइन आउट।
• OpenID/OAuth 2.0/SAML समर्थन।
• पहिचान ब्रोकरिङ - बाह्य OpenID जडान वा SAML पहिचान प्रदायकहरू प्रयोग गरेर प्रमाणीकरण।
• सामाजिक लगइन - प्रयोगकर्ता पहिचानको लागि Google, GitHub, Facebook, Twitter समर्थन।
• प्रयोगकर्ता महासंघ - LDAP र सक्रिय निर्देशिका सर्भरहरू र अन्य पहिचान प्रदायकहरूबाट प्रयोगकर्ताहरूको सिङ्क्रोनाइजेसन।
• Kerberos bridge - स्वचालित प्रयोगकर्ता प्रमाणीकरणको लागि Kerberos सर्भर प्रयोग गर्दै।
• Admin Console - वेब मार्फत सेटिङहरू र समाधान विकल्पहरूको एकीकृत व्यवस्थापनको लागि।
• खाता व्यवस्थापन कन्सोल - प्रयोगकर्ता प्रोफाइलको स्व-व्यवस्थापनको लागि।
• कम्पनीको कर्पोरेट पहिचानमा आधारित समाधानको अनुकूलन।
• 2FA प्रमाणीकरण - गुगल प्रमाणक वा FreeOTP प्रयोग गरेर TOTP/HOTP समर्थन।
• लगइन प्रवाहहरू - प्रयोगकर्ता आत्म-दर्ता, पासवर्ड रिकभरी र रिसेट, र अन्य सम्भव छन्।
• सत्र व्यवस्थापन - प्रशासकहरूले एकल बिन्दुबाट प्रयोगकर्ता सत्रहरू व्यवस्थापन गर्न सक्छन्।
• टोकन म्यापरहरू - टोकनहरूमा प्रयोगकर्ता विशेषताहरू, भूमिकाहरू र अन्य आवश्यक विशेषताहरू बाध्यकारी।
• दायरा, अनुप्रयोग र प्रयोगकर्ताहरूमा लचिलो नीति व्यवस्थापन।
• CORS समर्थन - ग्राहक एडेप्टरहरूमा निर्मित CORS समर्थन छ।
• सेवा प्रदायक इन्टरफेसहरू (SPI) - SPI हरूको ठूलो संख्या जसले तपाईंलाई सर्भरका विभिन्न पक्षहरूलाई अनुकूलन गर्न अनुमति दिन्छ: प्रमाणीकरण प्रवाह, पहिचान प्रदायकहरू, प्रोटोकल म्यापिङ, र थप।
• JavaScript अनुप्रयोगहरूका लागि क्लाइन्ट एडेप्टरहरू, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring।
• OpenID Connect Relying Party Library वा SAML 2.0 सेवा प्रदायक पुस्तकालयलाई समर्थन गर्ने विभिन्न अनुप्रयोगहरूसँग काम गर्नको लागि समर्थन।
• प्लगइनहरू प्रयोग गरेर विस्तार गर्न सकिने।

CI/CD प्रक्रियाहरूको लागि, साथै Keycloak मा व्यवस्थापन प्रक्रियाहरूको स्वचालन, REST API/JAVA API प्रयोग गर्न सकिन्छ। कागजात इलेक्ट्रोनिक रूपमा उपलब्ध छ:

REST API https://www.keycloak.org/docs-api/8.0/rest-api/index.html
Java API https://www.keycloak.org/docs-api/8.0/javadocs/index.html

उद्यम पहिचान प्रदायकहरू (अन-प्रिमाइस)

प्रयोगकर्ता संघ सेवाहरू मार्फत प्रयोगकर्ताहरूलाई प्रमाणीकरण गर्ने क्षमता।

पास-थ्रु प्रमाणिकरण पनि प्रयोग गर्न सकिन्छ - यदि प्रयोगकर्ताहरू Kerberos (LDAP वा AD) को साथ कार्यस्थानहरूमा प्रमाणिकरण गरिएका छन्, तब तिनीहरूले तिनीहरूको प्रयोगकर्ता नाम र पासवर्ड फेरि प्रदान नगरीकन स्वचालित रूपमा किक्लोकमा प्रमाणीकरण गर्न सकिन्छ।

प्रयोगकर्ताहरूको प्रमाणीकरण र थप प्राधिकरणको लागि, यो रिलेसनल DBMS प्रयोग गर्न सम्भव छ, जुन विकास वातावरणको लागि सबैभन्दा लागू हुन्छ, किनकि यसले परियोजनाहरूको प्रारम्भिक चरणहरूमा लामो सेटिङहरू र एकीकरणहरू समावेश गर्दैन। पूर्वनिर्धारित रूपमा, Keycloak सेटिङहरू र प्रयोगकर्ता डेटा भण्डारण गर्न निर्मित DBMS प्रयोग गर्दछ।

समर्थित DBMS को सूची व्यापक छ र यसमा समावेश छ: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle र अन्य। अहिलेसम्म सबैभन्दा धेरै परीक्षण गरिएको Oracle 12C Release1 RAC र Galera 3.12 क्लस्टर MariaDB 10.1.19 को लागि हो।

पहिचान प्रदायकहरू - सामाजिक लगइन

सामाजिक सञ्जालबाट लगइन प्रयोग गर्न सम्भव छ। प्रयोगकर्ताहरूलाई प्रमाणीकरण गर्ने क्षमता सक्रिय गर्न, Keycloack प्रशासक कन्सोल प्रयोग गर्नुहोस्। अनुप्रयोग कोडमा परिवर्तनहरू आवश्यक पर्दैन र यो कार्यक्षमता बाकस बाहिर उपलब्ध छ र परियोजनाको कुनै पनि चरणमा सक्रिय गर्न सकिन्छ।

प्रयोगकर्ताहरूलाई प्रमाणीकरण गर्न, OpenID/SAML पहिचान प्रदायकहरू प्रयोग गर्न सम्भव छ।

Keycloak मा OAuth2 प्रयोग गरेर विशिष्ट प्राधिकरण परिदृश्यहरू

प्राधिकरण कोड प्रवाह - सर्भर-साइड अनुप्रयोगहरूसँग प्रयोग गरियो। प्राधिकरण अनुमतिको सबैभन्दा सामान्य प्रकार मध्ये एक किनभने यो सर्भर-साइड अनुप्रयोगहरूको लागि उपयुक्त छ जहाँ अनुप्रयोगको स्रोत कोड र क्लाइन्ट डेटा अरूलाई पहुँचयोग्य छैन। यस मामला मा प्रक्रिया पुनर्निर्देशन मा आधारित छ। एप्लिकेसनले प्रयोगकर्ता एजेन्ट (प्रयोगकर्ता-एजेन्ट) सँग कुराकानी गर्न सक्षम हुनुपर्दछ, जस्तै वेब ब्राउजर, प्रयोगकर्ता एजेन्ट मार्फत फर्वार्ड गरिएका API प्राधिकरण कोडहरू प्राप्त गर्न।

निहित प्रवाह - मोबाइल वा वेब अनुप्रयोगहरू द्वारा प्रयोग गरिएको (प्रयोगकर्ताको उपकरणमा चलिरहेको अनुप्रयोगहरू)।

निहित प्राधिकरण अनुमति प्रकार मोबाइल र वेब अनुप्रयोगहरू द्वारा प्रयोग गरिन्छ जहाँ ग्राहकको गोपनीयताको ग्यारेन्टी हुन सक्दैन। निहित अनुमति प्रकारले प्रयोगकर्ता एजेन्ट पुनर्निर्देशन पनि प्रयोग गर्दछ, जसद्वारा पहुँच टोकन प्रयोगकर्ता एजेन्टलाई अनुप्रयोगमा थप प्रयोगको लागि पास गरिन्छ। यसले प्रयोगकर्ता र प्रयोगकर्ताको उपकरणमा अन्य अनुप्रयोगहरूलाई टोकन उपलब्ध गराउँछ। यस प्रकारको प्राधिकरण अनुमतिले एप्लिकेसनको पहिचान प्रमाणित गर्दैन, र प्रक्रिया आफैं रिडिरेक्ट URL मा निर्भर हुन्छ (पहिले सेवामा दर्ता गरिएको)।

इम्प्लिसिट फ्लोले पहुँच टोकन रिफ्रेस टोकनहरूलाई समर्थन गर्दैन।

ग्राहक प्रमाणहरू अनुदान प्रवाह - अनुप्रयोगले API पहुँच गर्दा प्रयोग गरिन्छ। यस प्रकारको प्राधिकरण अनुमति सामान्यतया सर्भर-टू-सर्भर अन्तरक्रियाहरूको लागि प्रयोग गरिन्छ जुन तत्काल प्रयोगकर्ता अन्तरक्रिया बिना पृष्ठभूमिमा प्रदर्शन गर्नुपर्छ। ग्राहक प्रमाणहरू अनुदान प्रवाहले वेब सेवा (गोपनीय ग्राहक) लाई अर्को वेब सेवालाई कल गर्दा प्रमाणीकरण गर्न प्रयोगकर्ताको नक्कल गर्नुको सट्टा आफ्नै प्रमाणहरू प्रयोग गर्न अनुमति दिन्छ। उच्च स्तरको सुरक्षाको लागि, कलिङ सेवाले प्रमाण पत्रको रूपमा (साझा गोप्यको सट्टा) प्रयोग गर्न सम्भव छ।

OAuth2 विशिष्टता मा वर्णन गरिएको छ
आरएफसी -१ 6749 १।
आरएफसी -१ 8252 १।
आरएफसी -१ 6819 १।

JWT टोकन र यसको फाइदाहरू

JWT (JSON वेब टोकन) एक खुला मानक हो (https://tools.ietf.org/html/rfc7519), जसले JSON वस्तुको रूपमा पक्षहरू बीचको जानकारी सुरक्षित रूपमा स्थानान्तरण गर्ने एउटा संकुचित र आत्म-निहित तरिका परिभाषित गर्दछ।

मानक अनुसार, टोकन आधार-64 ढाँचामा तीन भागहरू हुन्छन्, थोप्लाहरू द्वारा विभाजित। पहिलो भागलाई हेडर भनिन्छ, जसमा टोकनको प्रकार र डिजिटल हस्ताक्षर प्राप्त गर्नको लागि ह्यास एल्गोरिदमको नाम समावेश हुन्छ। दोस्रो भागले आधारभूत जानकारी (प्रयोगकर्ता, विशेषताहरू, आदि) भण्डार गर्दछ। तेस्रो भाग डिजिटल हस्ताक्षर हो।

। ।
आफ्नो DB मा टोकन कहिल्यै भण्डारण नगर्नुहोस्। किनकी वैध टोकन पासवर्डको बराबर हुन्छ, टोकन भण्डारण गर्नु भनेको स्पष्ट पाठमा पासवर्ड भण्डारण गर्नु जस्तै हो।
पहुँच टोकन एउटा टोकन हो जसले यसको मालिकलाई सुरक्षित सर्भर स्रोतहरूमा पहुँच प्रदान गर्दछ। यो सामान्यतया छोटो जीवनकाल हुन्छ र टोकन अनुरोध गर्ने पार्टीको IP ठेगाना जस्ता थप जानकारी बोक्न सक्छ।

टोकन रिफ्रेस गर्नुहोस् एक टोकन हो जसले ग्राहकहरूलाई उनीहरूको जीवनकाल समाप्त भएपछि नयाँ पहुँच टोकनहरू अनुरोध गर्न अनुमति दिन्छ। यी टोकनहरू सामान्यतया लामो समयको लागि जारी गरिन्छ।

माइक्रोसर्भिस आर्किटेक्चरमा प्रयोग गर्ने मुख्य फाइदाहरू:

• एक पटक प्रमाणीकरण मार्फत विभिन्न अनुप्रयोग र सेवाहरू पहुँच गर्ने क्षमता।
• प्रयोगकर्ता प्रोफाइलमा धेरै आवश्यक विशेषताहरूको अनुपस्थितिमा, स्वचालित र अन-द-फ्लाई सहित पेलोडमा थप्न सकिने डेटासँग समृद्ध गर्न सम्भव छ।
• सक्रिय सत्रहरूको बारेमा जानकारी भण्डारण गर्न आवश्यक छैन, सर्भर अनुप्रयोगले मात्र हस्ताक्षर प्रमाणित गर्न आवश्यक छ।
• पेलोडमा थप विशेषताहरू मार्फत थप लचिलो पहुँच नियन्त्रण।
• हेडर र पेलोडको लागि टोकन हस्ताक्षरको प्रयोगले समग्र रूपमा समाधानको सुरक्षा बढाउँछ।

JWT टोकन - रचना

हेडर - पूर्वनिर्धारित रूपमा, हेडरले टोकनको प्रकार र एन्क्रिप्शनको लागि प्रयोग गरिएको एल्गोरिदम मात्र समावेश गर्दछ।

टोकनको प्रकार "टाइप" कुञ्जीमा भण्डार गरिएको छ। JWT मा 'प्रकार' कुञ्जीलाई बेवास्ता गरिएको छ। यदि "typ" कुञ्जी अवस्थित छ भने, यो वस्तु JSON वेब टोकन हो भनेर संकेत गर्न यसको मान JWT हुनुपर्छ।

दोस्रो कुञ्जी "alg" ले टोकन इन्क्रिप्ट गर्न प्रयोग गरिने एल्गोरिदम परिभाषित गर्दछ। यो पूर्वनिर्धारित रूपमा HS256 मा सेट हुनुपर्छ। हेडर बेस64 मा एन्कोड गरिएको छ।

{ "alg": "HS256", "प्रकार": "JWT"}
पेलोड (सामग्री) - पेलोडले कुनै पनि जानकारी भण्डारण गर्दछ जुन जाँच गर्न आवश्यक छ। पेलोडमा प्रत्येक कुञ्जीलाई "दावी" भनिन्छ। उदाहरण को लागी, तपाइँ निमन्त्रणा द्वारा मात्र आवेदन प्रविष्ट गर्न सक्नुहुन्छ (बन्द प्रोमो)। जब हामी कसैलाई सहभागी हुन आमन्त्रित गर्न चाहन्छौं, हामी तिनीहरूलाई निमन्त्रणा इमेल पठाउँछौं। इमेल ठेगाना निमन्त्रणा स्वीकार गर्ने व्यक्तिको हो भनेर प्रमाणित गर्न महत्त्वपूर्ण छ, त्यसैले हामी यो ठेगानालाई "इमेल" कुञ्जीमा भण्डारण गरेर पेलोडमा समावेश गर्नेछौं।

{ "इमेल": "[ईमेल सुरक्षित]"}

पेलोडमा कुञ्जीहरू मनमानी हुन सक्छन्। यद्यपि, त्यहाँ केही आरक्षित छन्:

• iss (जारीकर्ता) - टोकन पठाइएको अनुप्रयोग पहिचान गर्दछ।
• उप (विषय) - टोकनको विषय परिभाषित गर्दछ।
• aud (दर्शक) केस-सेन्सेटिभ स्ट्रिङ वा URI हरूको एर्रे हो जुन यो टोकन प्राप्तकर्ताहरूको सूची हो। जब प्राप्त गर्ने पक्षले दिइएको कुञ्जीसँग JWT प्राप्त गर्दछ, यसले प्रापकहरूमा आफैंको उपस्थितिको लागि जाँच गर्नुपर्छ - अन्यथा टोकनलाई बेवास्ता गर्नुहोस्।
• exp (समय समाप्ति समय) - संकेत गर्दछ जब टोकन समाप्त हुन्छ। JWT मानकले यसको सबै कार्यान्वयनलाई म्याद सकिएको टोकनहरू अस्वीकार गर्न आवश्यक छ। exp कुञ्जी युनिक्स ढाँचामा टाइमस्ट्याम्प हुनुपर्छ।
• nbf (पहिले होइन) यूनिक्स ढाँचामा एक समय हो जसले टोकन मान्य हुने क्षण निर्धारण गर्दछ।
• iat (जारी गरिएको मा) - यो कुञ्जीले टोकन जारी गरिएको समयलाई प्रतिनिधित्व गर्दछ र JWT को उमेर निर्धारण गर्न प्रयोग गर्न सकिन्छ। iat कुञ्जी युनिक्स ढाँचामा टाइमस्ट्याम्प हुनुपर्छ।
• Jti (JWT ID) - एउटा स्ट्रिङ जसले यो टोकनको अद्वितीय पहिचानकर्ता परिभाषित गर्छ, केस-संवेदनशील।

यो बुझ्न महत्त्वपूर्ण छ कि पेलोड इन्क्रिप्टेड फारममा प्रसारित हुँदैन (यद्यपि टोकनहरू नेस्ट गर्न सकिन्छ र त्यसपछि इन्क्रिप्टेड डाटा प्रसारण गर्न सम्भव छ)। त्यसकारण, यसले कुनै पनि गोप्य जानकारी भण्डारण गर्न सक्दैन। हेडर जस्तै, पेलोड बेस64 एन्कोड गरिएको छ।
हस्ताक्षर - जब हामीसँग शीर्षक र पेलोड हुन्छ, हामी हस्ताक्षर गणना गर्न सक्छौं।

Base64-इन्कोडेड: हेडर र पेलोड लिइन्छ, तिनीहरू डट मार्फत स्ट्रिङमा जोडिएका छन्। त्यसपछि यो स्ट्रिङ र गोप्य कुञ्जी हेडर ("alg" कुञ्जी) मा निर्दिष्ट गरिएको एन्क्रिप्शन एल्गोरिदममा इनपुट हुन्छ। कुञ्जी कुनै पनि स्ट्रिङ हुन सक्छ। लामो स्ट्रिङहरू सबैभन्दा रुचाइनेछ किनभने यो उठाउन धेरै समय लाग्नेछ।

{"alg":"RSA1_5","payload":"A128CBC-HS256"}

कीक्लोक फेलओभर क्लस्टर आर्किटेक्चर निर्माण गर्दै

सबै परियोजनाहरूको लागि एकल क्लस्टर प्रयोग गर्दा, त्यहाँ SSO समाधानको लागि बढ्दो आवश्यकताहरू छन्। जब परियोजनाहरूको संख्या सानो हुन्छ, यी आवश्यकताहरू सबै परियोजनाहरूको लागि त्यति महत्त्वपूर्ण हुँदैनन्, तथापि, प्रयोगकर्ताहरू र एकीकरणहरूको संख्या बढ्दै जाँदा, उपलब्धता र कार्यसम्पादनको लागि आवश्यकताहरू बढ्दै जान्छ।

एकल SSO विफलताको जोखिम बढाउँदा समाधान वास्तुकलाका लागि आवश्यकताहरू र अनावश्यक घटकहरूको लागि प्रयोग गरिएका विधिहरू बढ्छ र धेरै तंग SLA निम्त्याउँछ। यस सन्दर्भमा, प्रायः विकास वा समाधानहरू कार्यान्वयनको प्रारम्भिक चरणहरूमा, परियोजनाहरूको आफ्नै गैर-गल्ती-सहिष्णु पूर्वाधारहरू हुन्छन्। विकासको गति बढ्दै जाँदा, विकास र मापनका लागि अवसरहरू राख्न आवश्यक छ। कन्टेनर भर्चुअलाइजेशन वा हाइब्रिड दृष्टिकोण प्रयोग गरेर फेलओभर क्लस्टर निर्माण गर्न यो धेरै लचिलो छ।

सक्रिय/सक्रिय र सक्रिय/निष्क्रिय क्लस्टर मोडहरूमा काम गर्न, यो एक रिलेशनल डाटाबेसमा डाटा स्थिरता सुनिश्चित गर्न आवश्यक छ - दुबै डाटाबेस नोडहरू विभिन्न भू-वितरित डाटा केन्द्रहरू बीच सिंक्रोनस रूपमा प्रतिकृति हुनुपर्छ।

एक दोष-सहिष्णु स्थापना को सरल उदाहरण।

एकल क्लस्टर प्रयोग गर्दा के फाइदाहरू छन्:

• उच्च उपलब्धता र प्रदर्शन।
• अपरेटिङ मोडहरूको लागि समर्थन: सक्रिय / सक्रिय, सक्रिय / निष्क्रिय।
• गतिशील स्केलिंगको सम्भावना - कन्टेनर भर्चुअलाइजेशन प्रयोग गर्दा।
• केन्द्रीकृत व्यवस्थापन र अनुगमनको सम्भावना।
• परियोजनाहरूमा प्रयोगकर्ताहरूको पहिचान/प्रमाणीकरण/प्राधिकरणको लागि एक एकीकृत दृष्टिकोण।
• प्रयोगकर्ता अन्तरक्रिया बिना विभिन्न परियोजनाहरु बीच अधिक पारदर्शी अन्तरक्रिया।
• विभिन्न परियोजनाहरूमा JWT टोकन पुन: प्रयोग गर्ने क्षमता।
• विश्वासको एकल बिन्दु।
• माइक्रोसर्भिसेस/कन्टेनर भर्चुअलाइजेसन प्रयोग गरेर परियोजनाहरूको द्रुत सुरुवात (अतिरिक्त कम्पोनेन्टहरू लिफ्ट र कन्फिगर गर्न आवश्यक छैन)।
• विक्रेताबाट व्यावसायिक समर्थन खरिद गर्न सम्भव छ।

क्लस्टर योजना बनाउँदा के खोज्ने

DBMS

किक्लोकले भण्डारण गर्न डाटाबेस व्यवस्थापन प्रणाली प्रयोग गर्दछ: क्षेत्रहरू, ग्राहकहरू, प्रयोगकर्ताहरू, इत्यादि।
DBMS को एक विस्तृत श्रृंखला समर्थित छ: MS SQL, Oracle, MySQL, PostgreSQL। कीक्लोक यसको आफ्नै निर्मित रिलेशनल डाटाबेसको साथ आउँछ। यसलाई गैर-लोड गरिएको वातावरणको लागि प्रयोग गर्न सिफारिस गरिन्छ - जस्तै विकास वातावरण।

सक्रिय/सक्रिय र सक्रिय/निष्क्रिय क्लस्टर मोडहरूमा काम गर्न, एक रिलेशनल डाटाबेसमा डाटा स्थिरता आवश्यक छ, र दुबै डाटाबेस क्लस्टर नोडहरू डेटा केन्द्रहरू बीच सिंक्रोनस रूपमा प्रतिकृति हुन्छन्।

वितरित क्यास (Infinspan)

क्लस्टरले ठीकसँग काम गर्नको लागि, JBoss डाटा ग्रिड प्रयोग गरेर निम्न प्रकारका क्यासहरूको अतिरिक्त सिङ्क्रोनाइजेसन आवश्यक छ:

प्रमाणीकरण सत्रहरू - एक विशिष्ट प्रयोगकर्ता प्रमाणीकरण गर्दा डाटा बचत गर्न प्रयोग गरिन्छ। यस क्यासबाट अनुरोधहरूले सामान्यतया ब्राउजर र कीक्लोक सर्भर मात्र समावेश गर्दछ, अनुप्रयोग होइन।

कार्य टोकनहरू - परिदृश्यहरूको लागि प्रयोग गरिन्छ जहाँ प्रयोगकर्तालाई एसिन्क्रोनस रूपमा (इमेल मार्फत) कार्य पुष्टि गर्न आवश्यक हुन्छ। उदाहरणका लागि, पासवर्ड बिर्सने क्रममा, Infinispan actionTokens क्यास पहिले नै प्रयोग भइसकेका सम्बद्ध कार्य टोकनहरूको बारेमा मेटाडेटा ट्र्याक राख्न प्रयोग गरिन्छ, त्यसैले यसलाई पुन: प्रयोग गर्न सकिँदैन।

क्यासिङ र पर्सिस्टेन्ट डाटाको अमान्यकरण - डाटाबेसमा अनावश्यक प्रश्नहरूबाट बच्न लगातार डाटा क्यास गर्न प्रयोग गरिन्छ। जब कुनै पनि कीक्लोक सर्भरले डाटा अपडेट गर्छ, सबै डाटा केन्द्रहरूमा अन्य सबै कीक्लोक सर्भरहरूले यसको बारेमा जान्नुपर्दछ।

कार्य - केवल क्लस्टर नोडहरू र डेटा केन्द्रहरू बीच अवैध सन्देशहरू पठाउन प्रयोग गरिन्छ।

प्रयोगकर्ता सत्रहरू - प्रयोगकर्ता सत्र डाटा भण्डारण गर्न प्रयोग गरिन्छ जुन प्रयोगकर्ताको ब्राउजर सत्रको अवधिको लागि मान्य हुन्छ। क्यासले अन्तिम प्रयोगकर्ता र अनुप्रयोगबाट HTTP अनुरोधहरू प्रशोधन गर्नुपर्छ।

ब्रुट फोर्स प्रोटेक्शन - असफल लगइनहरूको बारेमा डाटा ट्र्याक गर्न प्रयोग गरियो।

लोड सन्तुलन

लोड ब्यालेन्सर किक्लोकमा एकल प्रविष्टि बिन्दु हो र टाँसिने सत्रहरूलाई समर्थन गर्नुपर्छ।

आवेदन सर्भरहरू

तिनीहरू एकअर्कासँग कम्पोनेन्टहरूको अन्तरक्रिया नियन्त्रण गर्न प्रयोग गरिन्छ र अवस्थित स्वचालन उपकरणहरू र पूर्वाधार स्वचालन उपकरणहरूको गतिशील स्केलिंग प्रयोग गरेर भर्चुअलाइज वा कन्टेनराइज गर्न सकिन्छ। OpenShift, Kubernates, Rancher मा सबैभन्दा सामान्य तैनाती परिदृश्यहरू।

यो पहिलो भाग समाप्त हुन्छ - सैद्धांतिक एक। लेखहरूको अर्को शृङ्खलामा, विभिन्न पहिचान प्रदायकहरूसँग एकीकरणका उदाहरणहरू र सेटिङहरूको उदाहरणहरू विश्लेषण गरिनेछ।

स्रोत: www.habr.com