ક્લાઉડ સેવાની રચનાનો ઇતિહાસ, સાયબરપંક સાથે અનુભવી

જેમ જેમ તમે IT માં કામ કરો છો, તેમ તમે નોંધવાનું શરૂ કરો છો કે સિસ્ટમ્સનું પોતાનું પાત્ર છે. તેઓ લવચીક, શાંત, તરંગી અને કડક હોઈ શકે છે. તેઓ આકર્ષિત અથવા ભગાડી શકે છે. એક યા બીજી રીતે, તમારે તેમની સાથે “વાટાઘાટો” કરવી પડશે, “મુશ્કેલીઓ” વચ્ચે દાવપેચ કરવી પડશે અને તેમની ક્રિયાપ્રતિક્રિયાની સાંકળો બનાવવી પડશે.

તેથી અમને ક્લાઉડ પ્લેટફોર્મ બનાવવાનું સન્માન મળ્યું, અને આ માટે અમારે અમારી સાથે કામ કરવા માટે કેટલીક સબસિસ્ટમને "મનાવવા"ની જરૂર હતી. સદનસીબે, અમારી પાસે “API ભાષા”, સીધા હાથ અને ઘણો ઉત્સાહ છે.

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

બિલાડીમાં આપનું સ્વાગત છે.

પ્રવાસની શરૂઆત

થોડા સમય પહેલા, અમારી ટીમને અમારા ગ્રાહકો માટે ક્લાઉડ પ્લેટફોર્મ લોન્ચ કરવાનું કામ સોંપવામાં આવ્યું હતું. સેવાના સોફ્ટવેર ભાગને અમલમાં મૂકવા માટે અમારી પાસે મેનેજમેન્ટ સપોર્ટ, સંસાધનો, હાર્ડવેર સ્ટેક અને ટેકનોલોજી પસંદ કરવામાં સ્વતંત્રતા હતી.

ત્યાં પણ સંખ્યાબંધ આવશ્યકતાઓ હતી:

• સેવાને અનુકૂળ વ્યક્તિગત ખાતાની જરૂર છે;
• પ્લેટફોર્મ હાલની બિલિંગ સિસ્ટમમાં એકીકૃત હોવું જોઈએ;
• સોફ્ટવેર અને હાર્ડવેર: OpenStack + Tungsten Fabric (Open Contrail), જેને અમારા એન્જિનિયરોએ સારી રીતે "રસોઈ" કરવાનું શીખ્યા છે.

જો હાબ્રા સમુદાયને રસ હોય તો ટીમ કેવી રીતે એસેમ્બલ કરવામાં આવી હતી, વ્યક્તિગત એકાઉન્ટ ઇન્ટરફેસ વિકસાવવામાં આવી હતી અને ડિઝાઇન નિર્ણયો લેવામાં આવ્યા હતા તે વિશે અમે તમને બીજી વાર જણાવીશું.
અમે ઉપયોગ કરવાનું નક્કી કરેલ સાધનો:

• Python + Flask + Swagger + SQLAlchemy - એક સંપૂર્ણ પ્રમાણભૂત Python સેટ;
• અગ્ર માટે Vue.js;
• અમે AMQP પર સેલરીનો ઉપયોગ કરીને ઘટકો અને સેવાઓ વચ્ચે ક્રિયાપ્રતિક્રિયા કરવાનું નક્કી કર્યું.

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

તો, ચાલો આપણી ઓળખાણ શરૂ કરીએ.

સાયલન્ટ બિલ - બિલિંગ

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

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

ઉદાહરણ તરીકે, જ્યારે બનાવવામાં આવે અથવા કાઢી નાખવામાં આવે, ત્યારે કાર્ય આંતરિક બિલિંગ કતારમાં જાય છે. આમ, સેવાઓ સાથે અસુમેળ કાર્યની સિસ્ટમ લાગુ કરવામાં આવી છે. અમારી સેવાના પ્રકારો પર પ્રક્રિયા કરવા માટે, અમારે અમારા કાર્યોને આ કતારમાં "મૂકવા" જરૂરી છે. અને અહીં અમે એક સમસ્યામાં આવી ગયા: દસ્તાવેજોનો અભાવ.

સૉફ્ટવેર API ના વર્ણન દ્વારા અભિપ્રાય આપતા, હજી પણ આ સમસ્યાનું નિરાકરણ શક્ય છે, પરંતુ અમારી પાસે રિવર્સ એન્જિનિયરિંગ કરવાનો સમય નથી, તેથી અમે તર્કને બહાર કાઢ્યો અને RabbitMQ ની ટોચ પર એક કાર્ય કતાર ગોઠવી. ક્લાયન્ટ દ્વારા તેના અંગત ખાતામાંથી સેવા પરની કામગીરી શરૂ કરવામાં આવે છે, તે બેકએન્ડ પર સેલરી "ટાસ્ક"માં ફેરવાય છે અને બિલિંગ અને ઓપનસ્ટેક બાજુ પર કરવામાં આવે છે. સેલરી તે કાર્યોનું સંચાલન કરવા, પુનરાવર્તનો ગોઠવવા અને સ્થિતિનું નિરીક્ષણ કરવા માટે ખૂબ અનુકૂળ બનાવે છે. તમે "સેલેરી" વિશે વધુ વાંચી શકો છો, ઉદાહરણ તરીકે, અહીં.

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

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

બીજી સમસ્યા મૌન છે.

બિલી ચુપચાપ કેટલીક API વિનંતીઓને "ઓકે" પ્રતિસાદ આપે છે. આ કેસ હતો, ઉદાહરણ તરીકે, જ્યારે અમે પરીક્ષણ દરમિયાન વચન આપેલી ચૂકવણીની ચૂકવણી કરી હતી (તેના પર પછીથી વધુ). વિનંતીઓ યોગ્ય રીતે ચલાવવામાં આવી હતી અને અમને કોઈ ભૂલ દેખાઈ નથી.

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

સામાન્ય રીતે, દસ્તાવેજીકરણમાં ગાબડાં અને નાની API ભૂલો હોવા છતાં, બધું બરાબર ચાલ્યું. જો તમે સમજો કે તે કેવી રીતે રચાયેલ છે અને શું જોવું જોઈએ તો લોગ્સ ભારે ભાર હેઠળ પણ વાંચી શકાય છે. ડેટાબેઝનું માળખું અલંકૃત છે, પરંતુ તદ્દન તાર્કિક અને કેટલીક રીતે આકર્ષક પણ છે.

તેથી, સારાંશ માટે, ક્રિયાપ્રતિક્રિયાના તબક્કે અમે જે મુખ્ય સમસ્યાઓનો સામનો કર્યો તે ચોક્કસ સિસ્ટમના અમલીકરણની સુવિધાઓ સાથે સંબંધિત છે:

• બિનદસ્તાવેજીકૃત "સુવિધાઓ" જેણે અમને એક અથવા બીજી રીતે અસર કરી છે;
• ક્લોઝ્ડ સોર્સ (બિલિંગ C++ માં લખાયેલું છે), પરિણામે, “ટ્રાયલ અને એરર” સિવાય અન્ય કોઈપણ રીતે સમસ્યા 1 ને હલ કરવી અશક્ય છે.

સદભાગ્યે, ઉત્પાદનમાં એકદમ વ્યાપક API છે અને અમે અમારા વ્યક્તિગત ખાતામાં નીચેની સબસિસ્ટમને એકીકૃત કરી છે:

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

ટંગસ્ટન ક્ષેત્રોમાંથી ચાલવું - ટંગસ્ટન ફેબ્રિક

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

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

સિસ્ટમ ન્યુટ્રોન પ્લગઇન દ્વારા OpenStack (નીચે ચર્ચા કરેલ) સાથે સંકલિત છે.

OpenStack સેવાઓની ક્રિયાપ્રતિક્રિયા.

ઓપરેશન વિભાગના લોકોએ અમને આ સિસ્ટમ સાથે પરિચય કરાવ્યો. અમે અમારી સેવાઓના નેટવર્ક સ્ટેકનું સંચાલન કરવા માટે સિસ્ટમના API નો ઉપયોગ કરીએ છીએ. તેનાથી અમને હજુ સુધી કોઈ ગંભીર સમસ્યાઓ અથવા અસુવિધાઓ થઈ નથી (હું OE ના છોકરાઓ માટે બોલી શકતો નથી), પરંતુ ક્રિયાપ્રતિક્રિયામાં કેટલીક વિચિત્રતાઓ છે.

પ્રથમ આના જેવો દેખાતો હતો: આદેશો કે જેને SSH દ્વારા કનેક્ટ કરતી વખતે ઇન્સ્ટન્સ કન્સોલ પર મોટી માત્રામાં ડેટા આઉટપુટ કરવાની જરૂર પડે છે, જ્યારે કનેક્શનને ફક્ત "હેન્ગ અપ" કરવામાં આવે છે, જ્યારે VNC દ્વારા બધું યોગ્ય રીતે કાર્ય કરે છે.

જેઓ સમસ્યાથી પરિચિત નથી તેમના માટે, તે ખૂબ રમુજી લાગે છે: ls /root યોગ્ય રીતે કાર્ય કરે છે, જ્યારે, ઉદાહરણ તરીકે, ટોચનું "સ્થિર" સંપૂર્ણપણે. સદભાગ્યે, અમે પહેલા સમાન સમસ્યાઓનો સામનો કર્યો છે. કોમ્પ્યુટ નોડ્સથી રાઉટર સુધીના રૂટ પર MTU ને ટ્યુન કરીને નક્કી કરવામાં આવ્યું હતું. માર્ગ દ્વારા, આ TF સમસ્યા નથી.

આગળની સમસ્યા ખૂણાની આસપાસ જ હતી. એક "સુંદર" ક્ષણમાં, રૂટીંગનો જાદુ અદૃશ્ય થઈ ગયો, તે જ રીતે. TF એ સાધનો પર રૂટીંગનું સંચાલન કરવાનું બંધ કરી દીધું છે.

અમે એડમિન સ્તરથી ઓપનસ્ટૅક સાથે કામ કર્યું અને તે પછી જરૂરી વપરાશકર્તા સ્તર પર ગયા. SDN એ વપરાશકર્તાના અવકાશને "હાઇજેક" કરતું દેખાય છે જેના દ્વારા ક્રિયાઓ કરવામાં આવે છે. હકીકત એ છે કે સમાન એડમિન એકાઉન્ટનો ઉપયોગ TF અને OpenStack ને કનેક્ટ કરવા માટે થાય છે. વપરાશકર્તા પર સ્વિચ કરવાના પગલા પર, "જાદુ" અદૃશ્ય થઈ ગયો. સિસ્ટમ સાથે કામ કરવા માટે અલગ એકાઉન્ટ બનાવવાનું નક્કી કરવામાં આવ્યું હતું. આનાથી અમને એકીકરણ કાર્યક્ષમતાને તોડ્યા વિના કામ કરવાની મંજૂરી મળી.

સિલિકોન લાઇફફોર્મ્સ - ઓપનસ્ટેક

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

OpenStack એ અમારા પ્લેટફોર્મનો મુખ્ય ભાગ છે.

OpenStack પાસે ઘણી સબસિસ્ટમ્સ છે, જેમાંથી આપણે હાલમાં નોવા, ગ્લાન્સ અને સિન્ડરનો સૌથી વધુ સક્રિય રીતે ઉપયોગ કરીએ છીએ. તેમાંના દરેકનું પોતાનું API છે. નોવા સંસાધનોની ગણતરી કરવા અને ઉદાહરણોની રચના માટે જવાબદાર છે, સિન્ડર વોલ્યુમ અને તેમના સ્નેપશોટનું સંચાલન કરવા માટે જવાબદાર છે, ગ્લેન્સ એ ઇમેજ સેવા છે જે OS ટેમ્પ્લેટ્સ અને તેના પર મેટેનફોર્મેશનનું સંચાલન કરે છે.

દરેક સેવા કન્ટેનરમાં ચાલે છે, અને સંદેશ બ્રોકર "સફેદ સસલું" છે - RabbitMQ.

આ સિસ્ટમે અમને સૌથી અણધારી મુશ્કેલી આપી.

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

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

ડિસ્ક સાથે કામ કરતી વખતે બીજી મુશ્કેલી અમારી રાહ જોતી હતી. સિસ્ટમ વોલ્યુમ સર્વરથી ડિસ્કનેક્ટ કરી શકાયું નથી.

ફરીથી, OpenStack પોતે "શપથ લે છે" કે તેણે કનેક્શનનો નાશ કર્યો છે અને હવે તમે અલગથી વોલ્યુમ સાથે યોગ્ય રીતે કામ કરી શકો છો. પરંતુ API સ્પષ્ટપણે ડિસ્ક પર કામગીરી કરવા માંગતા ન હતા.

અહીં અમે ખાસ લડવાનું નહીં, પરંતુ સેવાના તર્ક પ્રત્યેના અમારા દૃષ્ટિકોણને બદલવાનું નક્કી કર્યું. જો કોઈ દાખલો હોય, તો ત્યાં સિસ્ટમ વોલ્યુમ પણ હોવું જોઈએ. તેથી, વપરાશકર્તા હજી સુધી "સર્વર" ને કાઢી નાખ્યા વિના સિસ્ટમ "ડિસ્ક" ને દૂર અથવા અક્ષમ કરી શકશે નહીં.

OpenStack એ તેના પોતાના ક્રિયાપ્રતિક્રિયા તર્ક અને અલંકૃત API સાથે સિસ્ટમોનો એક જટિલ સમૂહ છે. અમને એકદમ વિગતવાર દસ્તાવેજો અને, અલબત્ત, અજમાયશ અને ભૂલ (આપણે તેના વિના ક્યાં હોઈશું) દ્વારા મદદ કરવામાં આવે છે.

ટેસ્ટ રન

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

પરીક્ષણ પોતે, અલબત્ત, તેની રમુજી ક્ષણો વિના નહોતું, કારણ કે આ તે છે જ્યાં આપણા સાહસોની શરૂઆત થઈ રહી છે.

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

બીજી જિજ્ઞાસા તમારા વ્યક્તિગત ખાતામાં "પાસવર્ડ બદલો" બટનની કાર્યક્ષમતા સાથે સંબંધિત છે.

અમે અમારા વ્યક્તિગત ખાતાની ઍક્સેસ ગોઠવવા માટે JWT નો ઉપયોગ કરવાનું નક્કી કર્યું જેથી સત્રો સાથે કામ ન થાય. સિસ્ટમો વૈવિધ્યસભર અને વ્યાપકપણે વેરવિખેર હોવાથી, અમે અમારા પોતાના ટોકનનું સંચાલન કરીએ છીએ, જેમાં અમે બિલિંગમાંથી સત્રો અને OpenStack માંથી ટોકન "રપ" કરીએ છીએ. જ્યારે પાસવર્ડ બદલવામાં આવે છે, ત્યારે ટોકન, અલબત્ત, "ખરાબ થઈ જાય છે", કારણ કે વપરાશકર્તા ડેટા હવે માન્ય નથી અને તેને ફરીથી જારી કરવાની જરૂર છે.

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

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

ચાલુ રહી શકાય

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

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

અમે પહેલાથી જ તંત્રને સમજાવવામાં સફળ રહ્યા છીએ. બિલ તેના કબાટમાં ગણતરી, બિલિંગ અને વપરાશકર્તા વિનંતીઓનું ડ્યુટીપૂર્વક સંચાલન કરે છે. ટંગસ્ટન ક્ષેત્રોનો "જાદુ" અમને સ્થિર સંચાર પ્રદાન કરે છે. અને માત્ર OpenStack જ કેટલીકવાર તરંગી બની જાય છે, જેમ કે "'WSREP એ એપ્લિકેશનના ઉપયોગ માટે હજી સુધી નોડ તૈયાર કર્યો નથી." પરંતુ તે એક સંપૂર્ણપણે અલગ વાર્તા છે ...

અમે તાજેતરમાં સેવા શરૂ કરી છે.
તમે અમારા પર તમામ વિગતો શોધી શકો છો સાઇટ.

CLO વિકાસ ટીમ

ઉપયોગી લિંક્સ

ઓપનસ્ટેક

• https://docs.openstack.org/nova/latest/
• https://docs.openstack.org/keystone/latest/
• https://docs.openstack.org/cinder/latest/
• https://docs.openstack.org/glance/latest/

ટંગસ્ટન ફેબ્રિક

• http://docs.tungsten.io/en/latest/user/getting-started/index.html
• https://www.juniper.net/documentation/en_US/contrail-cloud10.0/topics/concept/contrail-cloud-openstack-integration-overview.html

સોર્સ: www.habr.com