કોન્સલ + iptables = :3

2010 માં કંપની યુદ્ધ રમત ત્યાં 50 સર્વર્સ અને એક સરળ નેટવર્ક મોડેલ હતા: બેકએન્ડ, ફ્રન્ટએન્ડ અને ફાયરવોલ. સર્વરોની સંખ્યામાં વધારો થયો, મોડેલ વધુ જટિલ બન્યું: સ્ટેજીંગ, ACLs સાથે અલગ VLANs, પછી VRFs સાથે VPNs, L2 પર ACLs સાથે VLANs, L3 પર ACLs સાથે VRFs. માથું ફરે છે? તે પછીથી વધુ મજા આવશે.

જ્યારે 16 સર્વર હતા, ત્યારે ઘણા વિજાતીય ભાગો સાથે આંસુ વિના કામ કરવું અશક્ય બની ગયું. તેથી અમે અન્ય ઉકેલ સાથે આવ્યા. અમે નેટફિલ્ટર સ્ટેક લીધો, તેમાં ડેટા સ્ત્રોત તરીકે કોન્સ્યુલ ઉમેર્યો, અને અમને ઝડપી વિતરિત ફાયરવોલ મળી. તેઓએ રાઉટર પર ACL ને બદલ્યા અને તેનો બાહ્ય અને આંતરિક ફાયરવોલ તરીકે ઉપયોગ કર્યો. ટૂલને ગતિશીલ રીતે મેનેજ કરવા માટે, અમે BEFW સિસ્ટમ વિકસાવી છે, જેનો ઉપયોગ દરેક જગ્યાએ કરવામાં આવતો હતો: ઉત્પાદન નેટવર્કમાં વપરાશકર્તાની ઍક્સેસને મેનેજ કરવાથી માંડીને નેટવર્ક સેગમેન્ટ્સને એકબીજાથી અલગ કરવા સુધી.

તે તમને કહેશે કે આ બધું કેવી રીતે કાર્ય કરે છે અને તમારે આ સિસ્ટમને શા માટે નજીકથી જોવી જોઈએ. ઇવાન અગારકોવ (વાર્ષિક) કંપનીના મિન્સ્ક વિકાસ કેન્દ્રમાં જાળવણી વિભાગના ઇન્ફ્રાસ્ટ્રક્ચર સુરક્ષા જૂથના વડા છે. ઇવાન SELinux ચાહક છે, પર્લને પ્રેમ કરે છે અને કોડ લખે છે. માહિતી સુરક્ષા જૂથના વડા તરીકે, તે વોરગેમિંગને હેકર્સથી બચાવવા અને કંપનીના તમામ ગેમ સર્વર્સના સંચાલનને સુનિશ્ચિત કરવા માટે નિયમિતપણે લોગ, બેકઅપ અને R&D સાથે કામ કરે છે.

ઐતિહાસિક પૃષ્ઠભૂમિ

અમે તે કેવી રીતે કર્યું તે હું તમને કહું તે પહેલાં, હું તમને કહીશ કે અમે આમાં પ્રથમ સ્થાને કેવી રીતે આવ્યા અને શા માટે તેની જરૂર હતી. આ કરવા માટે, ચાલો 9 વર્ષ પાછળ જઈએ: 2010, ટાંકીઓની દુનિયા હમણાં જ દેખાઈ. વોરગેમિંગમાં લગભગ 50 સર્વર્સ હતા.

કંપની સર્વર વૃદ્ધિ ચાર્ટ.

અમારી પાસે નેટવર્ક મોડેલ હતું. તે સમય માટે તે શ્રેષ્ઠ હતું.

2010 માં નેટવર્ક મોડેલ.

આગળના છેડે ખરાબ લોકો છે જેઓ આપણને તોડવા માંગે છે, પરંતુ તેમાં ફાયરવોલ છે. બેકએન્ડ પર કોઈ ફાયરવોલ નથી, પરંતુ ત્યાં 50 સર્વર્સ છે, અમે તે બધાને જાણીએ છીએ. બધું સારી રીતે કામ કરે છે.

4 વર્ષમાં, સર્વરનો કાફલો 100 ગણો વધીને 5000 થયો. પ્રથમ અલગ નેટવર્ક્સ દેખાયા - સ્ટેજિંગ: તેઓ ઉત્પાદન પર જઈ શકતા ન હતા, અને ઘણી વખત ત્યાં એવી વસ્તુઓ ચાલી રહી હતી જે જોખમી હોઈ શકે છે.

2014 માં નેટવર્ક મોડેલ.

જડતા દ્વારા, અમે હાર્ડવેરના સમાન ટુકડાઓનો ઉપયોગ કર્યો, અને તમામ કાર્ય અલગ VLAN પર હાથ ધરવામાં આવ્યું હતું: ACL VLAN ને લખવામાં આવે છે, જે અમુક પ્રકારના જોડાણને મંજૂરી આપે છે અથવા નકારે છે.

2016 માં, સર્વર્સની સંખ્યા 8000 સુધી પહોંચી. વોરગેમિંગે અન્ય સ્ટુડિયોને શોષી લીધા, અને વધારાના સંલગ્ન નેટવર્ક્સ દેખાયા. તેઓ અમારા હોય તેવું લાગે છે, પરંતુ તદ્દન નથી: VLAN ઘણીવાર ભાગીદારો માટે કામ કરતું નથી, તમારે VRF સાથે VPN નો ઉપયોગ કરવો પડશે, અલગતા વધુ જટિલ બની જાય છે. ACL ઇન્સ્યુલેશન મિશ્રણ વધ્યું.

2016 માં નેટવર્ક મોડેલ.

2018 ની શરૂઆત સુધીમાં, મશીનોનો કાફલો વધીને 16 થઈ ગયો હતો. ત્યાં 000 સેગમેન્ટ હતા, અને અમે બાકીની ગણતરી કરી ન હતી, જેમાં નાણાકીય ડેટા સંગ્રહિત કરવામાં આવ્યો હતો તે બંધનો સમાવેશ થાય છે. કન્ટેનર નેટવર્ક્સ (Kubernetes), DevOps, VPN દ્વારા જોડાયેલા ક્લાઉડ નેટવર્ક્સ, ઉદાહરણ તરીકે, IVS થી, દેખાયા છે. ત્યાં ઘણા નિયમો હતા - તે પીડાદાયક હતું.

2018 માં નેટવર્ક મોડેલ અને અલગતા પદ્ધતિઓ.

આઇસોલેશન માટે અમે ઉપયોગ કર્યો: L2 પર ACL સાથે VLAN, L3 પર ACL સાથે VRF, VPN અને ઘણું બધું. ઘણુ બધુ.

સમસ્યાઓ

દરેક વ્યક્તિ ACL અને VLAN સાથે રહે છે. ખોટુ શું છે? આ પ્રશ્નનો જવાબ હેરોલ્ડ દ્વારા આપવામાં આવશે, પીડા છુપાવી.

ત્યાં ઘણી સમસ્યાઓ હતી, પરંતુ પાંચ મોટા મુદ્દાઓ હતા.

• નવા નિયમો માટે ભૌમિતિક ભાવ વધારો. દરેક નવા નિયમને અગાઉના એક કરતાં ઉમેરવામાં વધુ સમય લાગ્યો, કારણ કે પહેલાથી આવો કોઈ નિયમ હતો કે કેમ તે જોવાનું જરૂરી હતું.
• સેગમેન્ટ્સની અંદર કોઈ ફાયરવોલ નથી. સેગમેન્ટ્સ કોઈક રીતે એકબીજાથી અલગ હતા, અને અંદર પહેલાથી પૂરતા સંસાધનો ન હતા.
• નિયમો લાંબા સમયથી લાગુ કરવામાં આવ્યા હતા. ઓપરેટરો એક કલાકમાં એક સ્થાનિક નિયમ હાથથી લખી શકે છે. વૈશ્વિક એકને ઘણા દિવસો લાગ્યા.
• ઓડિટ નિયમો સાથે મુશ્કેલીઓ. વધુ સ્પષ્ટ રીતે, તે શક્ય ન હતું. પ્રથમ નિયમો 2010 માં પાછા લખવામાં આવ્યા હતા, અને તેમના મોટાભાગના લેખકો હવે કંપની માટે કામ કરતા નથી.
• ઈન્ફ્રાસ્ટ્રક્ચર નિયંત્રણનું નીચું સ્તર. આ મુખ્ય સમસ્યા છે - આપણા દેશમાં શું ચાલી રહ્યું છે તે અમે સારી રીતે જાણતા ન હતા.

2018 માં નેટવર્ક એન્જિનિયર આના જેવો દેખાતો હતો જ્યારે તેણે સાંભળ્યું: "થોડી વધુ ACLની જરૂર છે."

ઉકેલો

2018 ની શરૂઆતમાં, તેના વિશે કંઈક કરવાનું નક્કી કરવામાં આવ્યું હતું.

એકીકરણની કિંમત સતત વધી રહી છે. શરૂઆતનો મુદ્દો એ હતો કે મોટા ડેટા સેન્ટરોએ આઇસોલેટેડ VLAN અને ACL ને સપોર્ટ કરવાનું બંધ કરી દીધું હતું કારણ કે ઉપકરણોની મેમરી સમાપ્ત થઈ ગઈ હતી.

ઉકેલ: અમે માનવ પરિબળ દૂર કર્યું અને મહત્તમ ઍક્સેસની જોગવાઈ સ્વચાલિત કરી.

નવા નિયમો લાગુ થવામાં ઘણો સમય લાગે છે. ઉકેલ: નિયમોના ઉપયોગને ઝડપી બનાવો, તેને વિતરિત અને સમાંતર બનાવો. આના માટે વિતરિત પ્રણાલીની જરૂર છે જેથી નિયમો જાતે જ વિતરિત થાય, rsync અથવા SFTP વગર હજાર સિસ્ટમમાં.

સેગમેન્ટની અંદર કોઈ ફાયરવોલ નથી. જ્યારે એક જ નેટવર્કમાં વિવિધ સેવાઓ દેખાય ત્યારે સેગમેન્ટમાં ફાયરવોલ અમારી પાસે આવવાનું શરૂ થયું. ઉકેલ: હોસ્ટ લેવલ પર ફાયરવોલનો ઉપયોગ કરો - હોસ્ટ-આધારિત ફાયરવોલ. લગભગ દરેક જગ્યાએ આપણી પાસે Linux છે, અને દરેક જગ્યાએ આપણી પાસે iptables છે, આ કોઈ સમસ્યા નથી.

ઓડિટ નિયમો સાથે મુશ્કેલીઓ. ઉકેલ: સમીક્ષા અને સંચાલન માટે તમામ નિયમો એક જ જગ્યાએ રાખો, જેથી અમે દરેક વસ્તુનું ઓડિટ કરી શકીએ.

ઈન્ફ્રાસ્ટ્રક્ચર પર નિયંત્રણનું નીચું સ્તર. ઉકેલ: તેમની વચ્ચેની તમામ સેવાઓ અને એક્સેસની ઇન્વેન્ટરી લો.

આ તકનીકી પ્રક્રિયા કરતાં વધુ વહીવટી પ્રક્રિયા છે. કેટલીકવાર અમારી પાસે અઠવાડિયામાં 200-300 નવી રિલીઝ હોય છે, ખાસ કરીને પ્રમોશન અને રજાઓ દરમિયાન. વધુમાં, આ ફક્ત અમારી DevOpsની એક ટીમ માટે છે. ઘણા બધા પ્રકાશનો સાથે, તે જોવાનું અશક્ય છે કે કયા પોર્ટ્સ, IPs અને એકીકરણની જરૂર છે. તેથી, અમને ખાસ પ્રશિક્ષિત સેવા સંચાલકોની જરૂર હતી જેમણે ટીમોને પૂછ્યું: "પણ ત્યાં શું છે અને તમે તેને શા માટે લાવ્યા?"

અમે જે બધું લોન્ચ કર્યું તે પછી, 2019 માં નેટવર્ક એન્જિનિયર આના જેવો દેખાવા લાગ્યો.

કોન્સ્યુલ

અમે નક્કી કર્યું કે સર્વિસ મેનેજર્સની મદદથી અમને જે કંઈ મળ્યું તે અમે કોન્સલમાં મૂકીશું અને ત્યાંથી અમે iptables નિયમો લખીશું.

અમે આ કેવી રીતે કરવાનું નક્કી કર્યું?

• અમે તમામ સેવાઓ, નેટવર્ક અને વપરાશકર્તાઓ એકત્રિત કરીશું.
• ચાલો તેના આધારે iptables નિયમો બનાવીએ.
• અમે નિયંત્રણ સ્વચાલિત કરીએ છીએ.
• ....
• નફો.

કોન્સ્યુલ એ રીમોટ API નથી, તે દરેક નોડ પર ચાલી શકે છે અને iptables પર લખી શકે છે. જે બાકી છે તે સ્વચાલિત નિયંત્રણો સાથે આવવાનું છે જે બિનજરૂરી વસ્તુઓને સાફ કરશે, અને મોટાભાગની સમસ્યાઓ હલ થઈ જશે! અમે જઈશું તેમ બાકીનું કામ કરીશું.

કોન્સ્યુલ શા માટે?

પોતાની જાતને સારી રીતે સાબિત કરી છે. 2014-15માં, અમે તેનો ઉપયોગ વૉલ્ટ માટે બેકએન્ડ તરીકે કર્યો હતો, જેમાં અમે પાસવર્ડ સ્ટોર કરીએ છીએ.

ડેટા ગુમાવતો નથી. ઉપયોગના સમય દરમિયાન, કોન્સુલે એક પણ અકસ્માત દરમિયાન ડેટા ગુમાવ્યો ન હતો. ફાયરવોલ મેનેજમેન્ટ સિસ્ટમ માટે આ એક વિશાળ વત્તા છે.

P2P જોડાણો પરિવર્તનના ફેલાવાને વેગ આપે છે. P2P સાથે, બધા ફેરફારો ઝડપથી આવે છે, કલાકો સુધી રાહ જોવાની જરૂર નથી.

અનુકૂળ REST API. અમે Apache ZooKeeper ને પણ માનીએ છીએ, પરંતુ તેની પાસે REST API નથી, તેથી તમારે crutches ઇન્સ્ટોલ કરવી પડશે.

કી વૉલ્ટ (KV) અને ડિરેક્ટરી (સર્વિસ ડિસ્કવરી) બંને તરીકે કામ કરે છે.. તમે એક જ સમયે સેવાઓ, કેટલોગ અને ડેટા સેન્ટર સ્ટોર કરી શકો છો. આ ફક્ત આપણા માટે જ નહીં, પરંતુ પડોશી ટીમો માટે પણ અનુકૂળ છે, કારણ કે વૈશ્વિક સેવા બનાવતી વખતે, અમે મોટું વિચારીએ છીએ.

Go માં લખાયેલ છે, જે Wargaming સ્ટેકનો ભાગ છે. અમને આ ભાષા ગમે છે, અમારી પાસે ઘણા ગો ડેવલપર્સ છે.

શક્તિશાળી ACL સિસ્ટમ. કોન્સ્યુલમાં, કોણ શું લખે છે તેને નિયંત્રિત કરવા માટે તમે ACL નો ઉપયોગ કરી શકો છો. અમે બાંહેધરી આપીએ છીએ કે ફાયરવોલ નિયમો અન્ય કોઈ પણ વસ્તુ સાથે ઓવરલેપ થશે નહીં અને અમને આમાં કોઈ સમસ્યા નહીં હોય.

પરંતુ કોન્સ્યુલમાં તેની ખામીઓ પણ છે.

• જ્યાં સુધી તમારી પાસે વ્યવસાય સંસ્કરણ ન હોય ત્યાં સુધી ડેટા સેન્ટરની અંદર માપન કરતું નથી. તે માત્ર ફેડરેશન દ્વારા માપી શકાય તેવું છે.
• નેટવર્ક અને સર્વર લોડની ગુણવત્તા પર ખૂબ આધાર રાખે છે. જો નેટવર્કમાં કોઈ ક્ષતિઓ હોય, ઉદાહરણ તરીકે, અસમાન ગતિ હોય તો વ્યસ્ત સર્વર પર સર્વર તરીકે કન્સ્યુલ યોગ્ય રીતે કામ કરશે નહીં. આ P2P કનેક્શન અને અપડેટ વિતરણ મોડલ્સને કારણે છે.
• ઉપલબ્ધતાનું નિરીક્ષણ કરવામાં મુશ્કેલી. કોન્સ્યુલ સ્ટેટસમાં તે કહી શકે છે કે બધું બરાબર છે, પરંતુ તે લાંબા સમય પહેલા મૃત્યુ પામ્યો હતો.

કોન્સ્યુલનો ઉપયોગ કરતી વખતે અમે આમાંની મોટાભાગની સમસ્યાઓ હલ કરી છે, તેથી જ અમે તેને પસંદ કર્યું છે. કંપની પાસે વૈકલ્પિક બેકએન્ડની યોજના છે, પરંતુ અમે સમસ્યાઓનો સામનો કરવાનું શીખ્યા છીએ અને હાલમાં અમે કોન્સલ સાથે રહીએ છીએ.

કોન્સ્યુલ કેવી રીતે કામ કરે છે

અમે શરતી ડેટા સેન્ટરમાં ત્રણથી પાંચ સર્વર ઇન્સ્ટોલ કરીશું. એક અથવા બે સર્વર કામ કરશે નહીં: જ્યારે ડેટા મેળ ખાતો નથી ત્યારે તેઓ કોરમ ગોઠવી શકશે નહીં અને કોણ સાચું છે અને કોણ ખોટું છે તે નક્કી કરી શકશે નહીં. પાંચથી વધુનો કોઈ અર્થ નથી, ઉત્પાદકતા ઘટશે.

ક્લાયંટ કોઈપણ ક્રમમાં સર્વર સાથે જોડાય છે: સમાન એજન્ટો, ફક્ત ધ્વજ સાથે server = false.

આ પછી, ગ્રાહકોને P2P કનેક્શન્સની સૂચિ મળે છે અને તેઓ એકબીજા સાથે જોડાણો બનાવે છે.

વૈશ્વિક સ્તરે, અમે ઘણા ડેટા કેન્દ્રોને જોડીએ છીએ. તેઓ P2P ને પણ જોડે છે અને વાતચીત કરે છે.

જ્યારે આપણે બીજા ડેટા સેન્ટરમાંથી ડેટા પુનઃપ્રાપ્ત કરવા માંગીએ છીએ, ત્યારે વિનંતી સર્વરથી સર્વર પર જાય છે. આ યોજના કહેવામાં આવે છે સર્ફ પ્રોટોકોલ. કોન્સલની જેમ Serf પ્રોટોકોલ, HashiCorp દ્વારા વિકસાવવામાં આવ્યો છે.

કોન્સ્યુલ વિશે કેટલીક મહત્વપૂર્ણ હકીકતો

કોન્સ્યુલ પાસે તે કેવી રીતે કાર્ય કરે છે તેનું વર્ણન કરતા દસ્તાવેજો છે. હું માત્ર પસંદગીના તથ્યો આપીશ જે જાણવા યોગ્ય છે.

કોન્સ્યુલ સર્વર્સ મતદારોમાંથી એક માસ્ટર પસંદ કરે છે. કોન્સ્યુલ દરેક ડેટા સેન્ટર માટે સર્વરની સૂચિમાંથી એક માસ્ટર પસંદ કરે છે, અને સર્વર્સની સંખ્યાને ધ્યાનમાં લીધા વિના, બધી વિનંતીઓ ફક્ત તેના પર જ જાય છે. માસ્ટર ફ્રીઝિંગ ફરીથી ચૂંટણી તરફ દોરી જતું નથી. જો માસ્ટર પસંદ કરેલ નથી, તો વિનંતીઓ કોઈપણ દ્વારા સેવા આપવામાં આવતી નથી.

શું તમે આડી સ્કેલિંગ કરવા માંગો છો? માફ કરશો, ના.

બીજા ડેટા સેન્ટરની વિનંતી માસ્ટરથી માસ્ટર સુધી જાય છે, પછી ભલે તે કયા સર્વર પર આવ્યો હોય. પસંદ કરેલ માસ્ટર ફોરવર્ડ વિનંતીઓ પરના ભારને બાદ કરતાં 100% લોડ મેળવે છે. ડેટા સેન્ટરના તમામ સર્વર્સ પાસે ડેટાની અપ-ટુ-ડેટ કોપી હોય છે, પરંતુ માત્ર એક જ જવાબ આપે છે.

સ્કેલ કરવાનો એકમાત્ર રસ્તો ક્લાયંટ પર વાસી મોડને સક્ષમ કરવાનો છે.

વાસી મોડમાં, તમે કોરમ વિના જવાબ આપી શકો છો. આ એક મોડ છે જેમાં અમે ડેટાની સુસંગતતા છોડી દઈએ છીએ, પરંતુ સામાન્ય કરતાં થોડી ઝડપથી વાંચીએ છીએ અને કોઈપણ સર્વર પ્રતિસાદ આપે છે. સ્વાભાવિક રીતે, માસ્ટર દ્વારા જ રેકોર્ડિંગ.

કોન્સ્યુલ ડેટા કેન્દ્રો વચ્ચે ડેટાની નકલ કરતું નથી. જ્યારે ફેડરેશન એસેમ્બલ થાય છે, ત્યારે દરેક સર્વર પાસે ફક્ત તેનો પોતાનો ડેટા હશે. અન્ય લોકો માટે, તે હંમેશા કોઈ બીજા તરફ વળે છે.

ટ્રાન્ઝેક્શનની બહાર ઓપરેશન્સની એટોમિસિટીની ખાતરી આપવામાં આવતી નથી. યાદ રાખો કે તમે એકલા નથી જે વસ્તુઓ બદલી શકે છે. જો તમે તેને અલગ રીતે ઈચ્છો છો, તો લૉક વડે વ્યવહાર કરો.

અવરોધિત કામગીરી લોકીંગની ખાતરી આપતી નથી. વિનંતી માસ્ટરથી માસ્ટર સુધી જાય છે, અને સીધી રીતે નહીં, તેથી કોઈ ગેરેંટી નથી કે જ્યારે તમે અવરોધિત કરો ત્યારે બ્લોકિંગ કાર્ય કરશે, ઉદાહરણ તરીકે, અન્ય ડેટા સેન્ટરમાં.

ACL પણ ઍક્સેસની ખાતરી આપતું નથી (ઘણા કિસ્સાઓમાં). ACL કદાચ કામ ન કરે કારણ કે તે એક ફેડરેશન ડેટા સેન્ટરમાં - ACL ડેટા સેન્ટર (પ્રાઈમરી DC)માં સંગ્રહિત છે. જો ડીસી તમને જવાબ નહીં આપે, તો ACL કામ કરશે નહીં.

એક સ્થિર માસ્ટર સમગ્ર ફેડરેશનને સ્થિર કરશે. ઉદાહરણ તરીકે, ફેડરેશનમાં 10 ડેટા સેન્ટર છે, અને એકનું નેટવર્ક ખરાબ છે, અને એક માસ્ટર નિષ્ફળ જાય છે. દરેક વ્યક્તિ જે તેની સાથે વાતચીત કરે છે તે એક વર્તુળમાં અટવાઇ જશે: ત્યાં એક વિનંતી છે, તેનો કોઈ જવાબ નથી, થ્રેડ સ્થિર થાય છે. આ ક્યારે થશે તે જાણવાનો કોઈ રસ્તો નથી, બસ એક-બે કલાકમાં આખું ફેડરેશન પડી જશે. તમે તેના વિશે કંઈ કરી શકતા નથી.

સ્થિતિ, કોરમ અને ચૂંટણી એક અલગ થ્રેડ દ્વારા નિયંત્રિત થાય છે. ફરી ચૂંટણી નહીં થાય, સ્ટેટસ કંઈ બતાવશે નહીં. તમને લાગે છે કે તમારી પાસે જીવંત કોન્સ્યુલ છે, તમે પૂછો, અને કંઈ થતું નથી - ત્યાં કોઈ જવાબ નથી. તે જ સમયે, સ્થિતિ બતાવે છે કે બધું બરાબર છે.

અમે આ સમસ્યાનો સામનો કર્યો છે અને તેને ટાળવા માટે ડેટા સેન્ટરના ચોક્કસ ભાગોનું પુનઃનિર્માણ કરવું પડ્યું છે.

કોન્સલ એન્ટરપ્રાઇઝના બિઝનેસ વર્ઝનમાં ઉપરના કેટલાક ગેરફાયદા નથી. તેમાં ઘણા ઉપયોગી કાર્યો છે: મતદારોની પસંદગી, વિતરણ, સ્કેલિંગ. ત્યાં માત્ર એક "પરંતુ" છે - વિતરિત સિસ્ટમ માટે લાઇસન્સિંગ સિસ્ટમ ખૂબ ખર્ચાળ છે.

જીવન હેકિંગ: rm -rf /var/lib/consul - એજન્ટના તમામ રોગો માટે ઉપચાર. જો કંઈક તમારા માટે કામ કરતું નથી, તો ફક્ત તમારો ડેટા કાઢી નાખો અને એક નકલમાંથી ડેટા ડાઉનલોડ કરો. મોટે ભાગે, કોન્સ્યુલ કામ કરશે.

BEFW

હવે આપણે કોન્સલમાં શું ઉમેર્યું છે તે વિશે વાત કરીએ.

BEFW માટે ટૂંકાક્ષર છે BACKEndFઇરWબધા. જ્યારે મેં તેમાં પ્રથમ ટેસ્ટ કમિટ્સ મૂકવા માટે રિપોઝીટરી બનાવી ત્યારે મારે કોઈક રીતે ઉત્પાદનનું નામ આપવું પડ્યું. આ નામ રહે છે.

નિયમ નમૂનાઓ

નિયમો iptables સિન્ટેક્સમાં લખાયેલા છે.

• -એન BEFW
• -P ઇનપુટ ડ્રોપ
• -એક ઇનપુટ -એમ રાજ્ય-રાજ્ય સંબંધિત, સ્થાપિત -જે સ્વીકારો
• -એક ઇનપુટ -i lo -j સ્વીકારો
• -એક ઇનપુટ -જે BEFW

બધું BEFW સાંકળમાં જાય છે, સિવાય ESTABLISHED, RELATED અને લોકલહોસ્ટ. નમૂના કંઈપણ હોઈ શકે છે, આ માત્ર એક ઉદાહરણ છે.

BEFW કેવી રીતે ઉપયોગી છે?

સેવાઓ

અમારી પાસે એક સેવા છે, તેમાં હંમેશા પોર્ટ હોય છે, નોડ હોય છે જેના પર તે ચાલે છે. અમારા નોડમાંથી, અમે સ્થાનિક રીતે એજન્ટને પૂછી શકીએ છીએ અને જાણી શકીએ છીએ કે અમારી પાસે અમુક પ્રકારની સેવા છે. તમે ટૅગ્સ પણ મૂકી શકો છો.

કોઈપણ સેવા કે જે ચાલી રહી છે અને કોન્સ્યુલ સાથે નોંધાયેલ છે તે iptables નિયમમાં ફેરવાય છે. અમારી પાસે SSH - ઓપન પોર્ટ 22 છે. Bash સ્ક્રિપ્ટ સરળ છે: curl અને iptables, બીજું કંઈ જરૂરી નથી.

ગ્રાહકો

દરેકને નહીં, પણ પસંદગીપૂર્વક ઍક્સેસ કેવી રીતે ખોલવી? સેવાના નામ દ્વારા KV સ્ટોરેજમાં IP યાદીઓ ઉમેરો.

ઉદાહરણ તરીકે, અમે ઇચ્છીએ છીએ કે દસમા નેટવર્ક પર દરેક વ્યક્તિ SSH_TCP_22 સેવાને ઍક્સેસ કરી શકે. એક નાનું TTL ફીલ્ડ ઉમેરો? અને હવે અમારી પાસે કામચલાઉ પરમિટ છે, ઉદાહરણ તરીકે, એક દિવસ માટે.

એક્સેસ

અમે સેવાઓ અને ગ્રાહકોને જોડીએ છીએ: અમારી પાસે એક સેવા છે, દરેક માટે KV સ્ટોરેજ તૈયાર છે. હવે અમે દરેકને નહીં, પણ પસંદગીપૂર્વક ઍક્સેસ આપીએ છીએ.

જૂથો

જો આપણે દર વખતે એક્સેસ માટે હજારો આઈપી લખીએ, તો આપણે થાકી જઈશું. ચાલો જૂથો સાથે આવીએ - KV માં એક અલગ સબસેટ. ચાલો તેને ઉપનામ (અથવા જૂથો) કહીએ અને સમાન સિદ્ધાંત અનુસાર જૂથોને ત્યાં સંગ્રહિત કરીએ.

ચાલો કનેક્ટ કરીએ: હવે આપણે SSH ખાસ P2P માટે નહીં, પરંતુ સમગ્ર જૂથ અથવા ઘણા જૂથો માટે ખોલી શકીએ છીએ. તે જ રીતે, ત્યાં TTL છે - તમે જૂથમાં ઉમેરી શકો છો અને જૂથમાંથી અસ્થાયી રૂપે દૂર કરી શકો છો.

એકીકરણ

અમારી સમસ્યા માનવ પરિબળ અને ઓટોમેશન છે. અત્યાર સુધી અમે તેને આ રીતે હલ કર્યું છે.

અમે પપેટ સાથે કામ કરીએ છીએ, અને સિસ્ટમ (એપ્લિકેશન કોડ) સાથે સંબંધિત દરેક વસ્તુ તેમને ટ્રાન્સફર કરીએ છીએ. Puppetdb (નિયમિત PostgreSQL) ત્યાં ચાલી રહેલી સેવાઓની સૂચિ સંગ્રહિત કરે છે, તે સંસાધન પ્રકાર દ્વારા શોધી શકાય છે. ત્યાં તમે શોધી શકો છો કે કોણ ક્યાં અરજી કરી રહ્યું છે. અમારી પાસે આ માટે પુલ રિક્વેસ્ટ અને મર્જ રિક્વેસ્ટ સિસ્ટમ પણ છે.

અમે befw-sync લખ્યું, એક સરળ ઉકેલ જે ડેટા ટ્રાન્સફર કરવામાં મદદ કરે છે. પ્રથમ, સિંક કૂકીઝને puppetdb દ્વારા એક્સેસ કરવામાં આવે છે. એક HTTP API ત્યાં ગોઠવેલ છે: અમે વિનંતી કરીએ છીએ કે અમારી પાસે કઈ સેવાઓ છે, શું કરવાની જરૂર છે. પછી તેઓ કોન્સ્યુલને વિનંતી કરે છે.

ત્યાં એકીકરણ છે? હા: તેઓએ નિયમો લખ્યા અને પુલ વિનંતીઓને સ્વીકારવાની મંજૂરી આપી. શું તમને કોઈ ચોક્કસ પોર્ટની જરૂર છે અથવા અમુક જૂથમાં હોસ્ટ ઉમેરવાની જરૂર છે? વિનંતી ખેંચો, સમીક્ષા કરો - વધુ નહીં "અન્ય 200 ACL શોધો અને તેના વિશે કંઈક કરવાનો પ્રયાસ કરો."

ઑપ્ટિમાઇઝેશન

ખાલી નિયમ સાંકળ સાથે લોકલહોસ્ટને પિંગ કરવા માટે 0,075 ms લાગે છે.

ચાલો આ સાંકળમાં 10 iptables સરનામાં ઉમેરીએ. પરિણામે, પિંગ 000 ગણો વધશે: iptables સંપૂર્ણપણે રેખીય છે, દરેક સરનામાં પર પ્રક્રિયા કરવામાં થોડો સમય લાગે છે.

ફાયરવોલ માટે જ્યાં અમે હજારો ACL ને સ્થાનાંતરિત કરીએ છીએ, અમારી પાસે ઘણા નિયમો છે, અને આ લેટન્સીનો પરિચય આપે છે. આ ગેમિંગ પ્રોટોકોલ માટે ખરાબ છે.

પરંતુ જો આપણે મૂકીએ ipset માં 10 સરનામાં પિંગ પણ ઘટશે.

મુદ્દો એ છે કે ipset માટે “O” (એલ્ગોરિધમ જટિલતા) હંમેશા 1 ની બરાબર હોય છે, પછી ભલે ગમે તેટલા નિયમો હોય. સાચું, ત્યાં એક મર્યાદા છે - ત્યાં 65535 થી વધુ નિયમો હોઈ શકતા નથી. હમણાં માટે અમે આ સાથે જીવીએ છીએ: તમે તેમને જોડી શકો છો, તેમને વિસ્તૃત કરી શકો છો, એકમાં બે ipsets બનાવી શકો છો.

સંગ્રહ

પુનરાવૃત્તિ પ્રક્રિયાનું તાર્કિક સાતત્ય એ ipset માં સેવા માટે ક્લાયન્ટ વિશેની માહિતીનો સંગ્રહ છે.

હવે અમારી પાસે સમાન SSH છે, અને અમે એકસાથે 100 IP લખતા નથી, પરંતુ જે ipset સાથે આપણે વાતચીત કરવાની જરૂર છે તેનું નામ સેટ કરીએ છીએ, અને નીચેનો નિયમ DROP. તેને એક નિયમમાં રૂપાંતરિત કરી શકાય છે “અહીં કોણ નથી, DROP”, પરંતુ તે વધુ સ્પષ્ટ છે.

હવે અમારી પાસે નિયમો અને સેટ છે. મુખ્ય કાર્ય નિયમ લખતા પહેલા સેટ બનાવવાનું છે, કારણ કે અન્યથા iptables નિયમ લખશે નહીં.

સામાન્ય યોજના

આકૃતિના રૂપમાં, મેં જે કહ્યું તે બધું આના જેવું લાગે છે.

અમે પપેટ માટે પ્રતિબદ્ધ છીએ, બધું યજમાનને મોકલવામાં આવે છે, અહીં સેવાઓ, ત્યાં ipset, અને જે કોઈ ત્યાં નોંધાયેલ નથી તેને મંજૂરી નથી.

મંજૂરી આપો અને નામંજૂર કરો

વિશ્વને ઝડપથી બચાવવા અથવા કોઈને ઝડપથી અક્ષમ કરવા માટે, બધી સાંકળોની શરૂઆતમાં અમે બે ipsets બનાવ્યાં: rules_allow и rules_deny. તે કેવી રીતે કામ કરે છે?

ઉદાહરણ તરીકે, કોઈ વ્યક્તિ બોટ્સ વડે અમારી વેબ પર લોડ બનાવી રહ્યું છે. પહેલાં, તમારે લોગમાંથી તેનો IP શોધવાનો હતો, તેને નેટવર્ક એન્જિનિયરો પાસે લઈ જવો હતો, જેથી તેઓ ટ્રાફિકનો સ્ત્રોત શોધી શકે અને તેના પર પ્રતિબંધ લાદી શકે. તે હવે અલગ દેખાય છે.

અમે તેને કોન્સલને મોકલીએ છીએ, 2,5 સેકન્ડ રાહ જુઓ અને તે થઈ ગયું. કોન્સ્યુલ P2P દ્વારા ઝડપથી વિતરણ કરે છે, તે વિશ્વના કોઈપણ ભાગમાં, દરેક જગ્યાએ કાર્ય કરે છે.

એકવાર મેં ફાયરવોલની ભૂલને કારણે WOTને સંપૂર્ણપણે બંધ કરી દીધું. rules_allow - આવા કેસો સામે આ અમારો વીમો છે. જો આપણે ફાયરવોલ સાથે ક્યાંક ભૂલ કરી હોય, કંઈક ક્યાંક અવરોધિત હોય, તો અમે હંમેશા શરતી મોકલી શકીએ છીએ 0.0/0ઝડપથી બધું પસંદ કરવા માટે. પછીથી આપણે હાથથી બધું ઠીક કરીશું.

અન્ય સેટ

તમે જગ્યામાં કોઈપણ અન્ય સેટ ઉમેરી શકો છો $IPSETS$.

શેના માટે? કેટલીકવાર કોઈને ipset ની જરૂર હોય છે, ઉદાહરણ તરીકે, ક્લસ્ટરના અમુક ભાગના શટડાઉનનું અનુકરણ કરવા માટે. કોઈપણ કોઈપણ સેટ લાવી શકે છે, તેનું નામ આપી શકે છે, અને તે કોન્સ્યુલ પાસેથી લેવામાં આવશે. તે જ સમયે, સેટ કાં તો iptables નિયમોમાં ભાગ લઈ શકે છે અથવા ટીમ તરીકે કાર્ય કરી શકે છે NOOP: ડિમન દ્વારા સુસંગતતા જાળવવામાં આવશે.

વપરાશકર્તાઓ

પહેલાં, તે આના જેવું હતું: વપરાશકર્તા નેટવર્ક સાથે જોડાયેલ છે અને ડોમેન દ્વારા પરિમાણો પ્રાપ્ત કરે છે. નવી પેઢીના ફાયરવોલના આગમન પહેલા, સિસ્કોને ખબર ન હતી કે વપરાશકર્તા ક્યાં છે અને IP ક્યાં છે તે કેવી રીતે સમજવું. તેથી, ફક્ત મશીનના હોસ્ટનામ દ્વારા જ ઍક્સેસ આપવામાં આવી હતી.

અમે શું કર્યું? સરનામું મળતાં જ અમે અટકી ગયા. સામાન્ય રીતે આ dot1x, Wi-Fi અથવા VPN છે - બધું RADIUS દ્વારા જાય છે. દરેક વપરાશકર્તા માટે, અમે વપરાશકર્તાનામ દ્વારા એક જૂથ બનાવીએ છીએ અને તેમાં TTL સાથે IP મૂકીએ છીએ જે તેના dhcp.lease સમાન હોય છે - જેમ તે સમાપ્ત થાય છે, તે નિયમ અદૃશ્ય થઈ જશે.

હવે અમે યુઝરનેમ દ્વારા અન્ય જૂથોની જેમ સેવાઓની ઍક્સેસ ખોલી શકીએ છીએ. અમે યજમાનનામો જ્યારે બદલાય છે ત્યારે તેમની પીડા દૂર કરી છે, અને અમે નેટવર્ક એન્જિનિયરો પરથી બોજ દૂર કર્યો છે કારણ કે તેમને હવે સિસ્કોની જરૂર નથી. હવે એન્જિનિયરો પોતે જ તેમના સર્વર પર એક્સેસ રજીસ્ટર કરે છે.

ઇંસ્યુલેશન

તે જ સમયે, અમે ઇન્સ્યુલેશનને તોડી નાખવાનું શરૂ કર્યું. સર્વિસ મેનેજરોએ ઇન્વેન્ટરી લીધી, અને અમે અમારા તમામ નેટવર્કનું વિશ્લેષણ કર્યું. ચાલો તેમને સમાન જૂથોમાં વિભાજીત કરીએ, અને જરૂરી સર્વર્સ પર જૂથો ઉમેરવામાં આવ્યા હતા, ઉદાહરણ તરીકે, નકારવા માટે. હવે સમાન સ્ટેજીંગ અલગતા ઉત્પાદનના નિયમો_નકારમાં સમાપ્ત થાય છે, પરંતુ ઉત્પાદનમાં જ નહીં.

સ્કીમ ઝડપથી અને સરળ રીતે કામ કરે છે: અમે સર્વર્સમાંથી તમામ ACL ને દૂર કરીએ છીએ, હાર્ડવેરને અનલોડ કરીએ છીએ અને અલગ VLAN ની સંખ્યા ઘટાડીએ છીએ.

અખંડિતતા નિયંત્રણ

પહેલાં, અમારી પાસે એક વિશિષ્ટ ટ્રિગર હતું જે જાણ કરે છે કે જ્યારે કોઈએ ફાયરવોલ નિયમ મેન્યુઅલી બદલ્યો હતો. હું ફાયરવોલ નિયમો તપાસવા માટે એક વિશાળ લિંટર લખી રહ્યો હતો, તે મુશ્કેલ હતું. અખંડિતતા હવે BEFW દ્વારા નિયંત્રિત છે. તે ઉત્સાહપૂર્વક ખાતરી કરે છે કે તે બનાવેલા નિયમોમાં ફેરફાર ન થાય. જો કોઈ ફાયરવોલ નિયમોમાં ફેરફાર કરે છે, તો તે બધું પાછું બદલી નાખશે. "મેં ઝડપથી પ્રોક્સી સેટ કરી છે જેથી હું ઘરેથી કામ કરી શકું"—આવા કોઈ વધુ વિકલ્પો નથી.

BEFW સેવાઓમાંથી ipset ને નિયંત્રિત કરે છે અને befw.conf માં યાદી આપે છે, BEFW સાંકળમાં સેવાઓના નિયમો. પરંતુ તે અન્ય સાંકળો અને નિયમો અને અન્ય ipsets પર દેખરેખ રાખતું નથી.

ક્રેશ પ્રોટેક્શન

BEFW હંમેશા છેલ્લી જાણીતી સારી સ્થિતિને સીધી state.bin બાઈનરી સ્ટ્રક્ચરમાં સ્ટોર કરે છે. જો કંઈક ખોટું થાય છે, તો તે હંમેશા આ રાજ્યમાં પાછા ફરે છે.

આ અસ્થિર કોન્સ્યુલ ઓપરેશન સામે વીમો છે, જ્યારે તેણે ડેટા મોકલ્યો ન હોય અથવા કોઈએ ભૂલ કરી હોય અને નિયમોનો ઉપયોગ કર્યો હોય જે લાગુ કરી શકાય નહીં. અમને ફાયરવોલ વિના છોડવામાં ન આવે તે સુનિશ્ચિત કરવા માટે, જો કોઈપણ તબક્કે ભૂલ થાય તો BEFW નવીનતમ સ્થિતિ પર પાછા ફરશે.

જટિલ પરિસ્થિતિઓમાં, આ ગેરંટી છે કે અમારી પાસે કાર્યરત ફાયરવોલ રહેશે. એડમિન આવશે અને તેને ઠીક કરશે તેવી આશા સાથે અમે બધા ગ્રે નેટવર્ક ખોલીએ છીએ. કોઈ દિવસ હું આને રૂપરેખાઓમાં મૂકીશ, પરંતુ હવે અમારી પાસે ફક્ત ત્રણ ગ્રે નેટવર્ક્સ છે: 10/8, 172/12 અને 192.168/16. અમારા કોન્સ્યુલની અંદર, આ એક મહત્વપૂર્ણ સુવિધા છે જે અમને વધુ વિકાસ કરવામાં મદદ કરે છે.

ડેમો: રિપોર્ટ દરમિયાન, ઇવાન BEFW ના ડેમો મોડનું નિદર્શન કરે છે. પ્રદર્શન જોવાનું સરળ છે видео. ડેમો સ્રોત કોડ ઉપલબ્ધ છે GitHub પર.

મુશ્કેલીઓ

અમે તમને મળેલી ભૂલો વિશે હું તમને જણાવીશ.

ipset ઉમેરો સેટ 0.0.0.0/0. જો તમે ipset માં 0.0.0.0/0 ઉમેરશો તો શું થશે? શું બધા IP ઉમેરવામાં આવશે? ઇન્ટરનેટ ઍક્સેસ ઉપલબ્ધ હશે?

ના, અમને એક બગ મળશે જેના કારણે બે કલાકનો ડાઉનટાઇમ ખર્ચ થશે. વધુમાં, બગ 2016 થી કામ કરતું નથી, તે RedHat Bugzilla માં નંબર #1297092 હેઠળ સ્થિત છે, અને અમે તેને અકસ્માતે શોધી કાઢ્યું - વિકાસકર્તાના અહેવાલમાંથી.

તે હવે BEFW પર કડક નિયમ છે 0.0.0.0/0 બે સરનામામાં ફેરવાય છે: 0.0.0.0/1 и 128.0.0.0/1.

ipset પુનઃસ્થાપિત સેટ < ફાઇલ. જ્યારે તમે તેને કહો ત્યારે ipset શું કરે છે restore? શું તમને લાગે છે કે તે iptables જેવું જ કામ કરે છે? શું તે ડેટા પુનઃપ્રાપ્ત કરશે?

એવું કંઈ નથી - તે મર્જ કરે છે, અને જૂના સરનામાં ક્યાંય જતા નથી, તમે ઍક્સેસને અવરોધિત કરતા નથી.

આઇસોલેશનનું પરીક્ષણ કરતી વખતે અમને એક ભૂલ મળી. હવે એક જગ્યાએ જટિલ સિસ્ટમ છે - તેના બદલે restore હાથ ધરવામાં create temp, પછી restore flush temp и restore temp. સ્વેપના અંતે: પરમાણુ માટે, કારણ કે જો તમે તે પહેલા કરો છો flush અને આ ક્ષણે કેટલાક પેકેટ આવે છે, તે કાઢી નાખવામાં આવશે અને કંઈક ખોટું થશે. તેથી ત્યાં કાળો જાદુ એક બીટ છે.

કોન્સ્યુલ kv get -datacenter=other. મેં કહ્યું તેમ, અમને લાગે છે કે અમે કેટલાક ડેટા માટે પૂછી રહ્યા છીએ, પરંતુ અમને કાં તો ડેટા અથવા ભૂલ મળશે. અમે કન્સ્યુલ દ્વારા સ્થાનિક રીતે આ કરી શકીએ છીએ, પરંતુ આ કિસ્સામાં બંને સ્થિર થઈ જશે.

સ્થાનિક કોન્સ્યુલ ક્લાયંટ એ HTTP API પર રેપર છે. પરંતુ તે ફક્ત અટકી જાય છે અને Ctrl+C, અથવા Ctrl+Z, અથવા કંઈપણને પ્રતિસાદ આપતું નથી, માત્ર kill -9 આગામી કન્સોલમાં. જ્યારે અમે એક મોટું ક્લસ્ટર બનાવી રહ્યા હતા ત્યારે અમને આનો સામનો કરવો પડ્યો. પરંતુ અમારી પાસે હજુ સુધી કોઈ ઉકેલ નથી; અમે કોન્સલમાં આ ભૂલ સુધારવાની તૈયારી કરી રહ્યા છીએ.

કોન્સ્યુલ લીડર જવાબ આપી રહ્યા નથી. ડેટા સેન્ટરમાં અમારા માસ્ટર પ્રતિસાદ આપતા નથી, અમને લાગે છે: "કદાચ ફરીથી પસંદગી અલ્ગોરિધમ હવે કામ કરશે?"

ના, તે કામ કરશે નહીં, અને દેખરેખ કંઈપણ બતાવશે નહીં: કોન્સ્યુલ કહેશે કે ત્યાં પ્રતિબદ્ધતા સૂચક છે, એક નેતા મળ્યો છે, બધું સારું છે.

અમે આ સાથે કેવી રીતે વ્યવહાર કરીએ? service consul restart દર કલાકે ક્રોનમાં. જો તમારી પાસે 50 સર્વર્સ છે, તો કોઈ મોટી વાત નથી. જ્યારે તેમાંના 16 હશે, ત્યારે તમે સમજી શકશો કે તે કેવી રીતે કાર્ય કરે છે.

નિષ્કર્ષ

પરિણામે, અમને નીચેના ફાયદાઓ પ્રાપ્ત થયા:

• તમામ Linux મશીનોનું 100% કવરેજ.
• ગતિ.
• ઓટોમેશન.
• અમે હાર્ડવેર અને નેટવર્ક એન્જિનિયરોને ગુલામીમાંથી મુક્ત કર્યા.
• એકીકરણની શક્યતાઓ દેખાઈ છે જે લગભગ અમર્યાદિત છે: કુબરનેટ્સ સાથે પણ, એન્સિબલ સાથે પણ, પાયથોન સાથે પણ.

મિનિસી: કોન્સ્યુલ, જેની સાથે આપણે હવે રહેવાનું છે, અને ભૂલની ખૂબ ઊંચી કિંમત. ઉદાહરણ તરીકે, એકવાર સાંજે 6 વાગ્યે (રશિયામાં પ્રાઇમ ટાઇમ) હું નેટવર્કની સૂચિમાં કંઈક સંપાદિત કરી રહ્યો હતો. અમે તે સમયે BEFW ખાતે માત્ર ઇન્સ્યુલેશન બનાવી રહ્યા હતા. મેં ક્યાંક ભૂલ કરી છે, એવું લાગે છે કે મેં ખોટો માસ્ક સૂચવ્યો છે, પરંતુ બધું બે સેકંડમાં પડી ગયું. મોનિટરિંગ લાઇટ થાય છે, ફરજ પરના સહાયક વ્યક્તિ દોડીને આવે છે: "અમારી પાસે બધું છે!" આ શા માટે થયું તે વ્યવસાયને સમજાવતા વિભાગના વડા ગ્રે થઈ ગયા.

ભૂલની કિંમત એટલી વધારે છે કે અમે અમારી પોતાની જટિલ નિવારણ પ્રક્રિયા સાથે આવ્યા છીએ. જો તમે આને મોટી પ્રોડક્શન સાઇટ પર લાગુ કરો છો, તો તમારે દરેકને કન્સ્યુલ પર માસ્ટર ટોકન આપવાની જરૂર નથી. આ ખરાબ રીતે સમાપ્ત થશે.

ખર્ચ મેં એકલા 400 કલાક માટે કોડ લખ્યો. મારી 4 લોકોની ટીમ દર મહિને 10 કલાક દરેકને સપોર્ટ કરવા માટે વિતાવે છે. કોઈપણ નવી પેઢીના ફાયરવોલની કિંમતની તુલનામાં, તે મફત છે.

યોજનાઓ. લાંબા ગાળાની યોજના કોન્સલને બદલવા અથવા પૂરક બનાવવા માટે વૈકલ્પિક પરિવહન શોધવાની છે. કદાચ તે કાફકા અથવા તેના જેવું જ કંઈક હશે. પરંતુ આગામી વર્ષોમાં અમે કોન્સ્યુલ પર રહીશું.

તાત્કાલિક યોજનાઓ: Fail2ban સાથે એકીકરણ, મોનિટરિંગ સાથે, nftables સાથે, સંભવતઃ અન્ય વિતરણો, મેટ્રિક્સ, એડવાન્સ મોનિટરિંગ, ઑપ્ટિમાઇઝેશન સાથે. કુબરનેટ્સ સપોર્ટ પણ ક્યાંક યોજનાઓમાં છે, કારણ કે હવે અમારી પાસે ઘણા ક્લસ્ટર અને ઇચ્છા છે.

યોજનાઓમાંથી વધુ:

• ટ્રાફિકમાં વિસંગતતાઓ માટે શોધો;
• નેટવર્ક મેપ મેનેજમેન્ટ;
• કુબરનેટ્સ સપોર્ટ;
• બધી સિસ્ટમો માટે પેકેજો એસેમ્બલીંગ;
• વેબ-UI.

અમે ગોઠવણીને વિસ્તૃત કરવા, મેટ્રિક્સ અને ઑપ્ટિમાઇઝેશન વધારવા પર સતત કામ કરી રહ્યા છીએ.

પ્રોજેક્ટમાં જોડાઓ. પ્રોજેક્ટ સરસ બન્યો, પરંતુ, કમનસીબે, તે હજી પણ એક-વ્યક્તિનો પ્રોજેક્ટ છે. આવે છે GitHub અને કંઈક કરવાનો પ્રયાસ કરો: પ્રતિબદ્ધ કરો, પરીક્ષણ કરો, કંઈક સૂચવો, તમારું મૂલ્યાંકન આપો.

દરમિયાન અમે તૈયારી કરી રહ્યા છીએ સેન્ટ હાઇલોડ++, જે 6 અને 7 એપ્રિલના રોજ સેન્ટ પીટર્સબર્ગમાં થશે અને અમે હાઇ-લોડ સિસ્ટમ્સના વિકાસકર્તાઓને આમંત્રિત કરીએ છીએ રિપોર્ટ માટે અરજી કરો. અનુભવી વક્તાઓ પહેલાથી જ જાણે છે કે શું કરવું, પરંતુ જેઓ બોલતા હોય તેઓ માટે અમે ઓછામાં ઓછા ભલામણ કરીએ છીએ પ્રયાસ કરવા માટે. કોન્ફરન્સમાં વક્તા તરીકે ભાગ લેવાના ઘણા ફાયદા છે. તમે વાંચી શકો છો કે કયા, ઉદાહરણ તરીકે, અંતે આ લેખ.

સોર્સ: www.habr.com