કઠોર એન્ટરપ્રાઇઝ વાતાવરણમાં "ફ્રી" પોસ્ટગ્રેએસક્યુએલને કેવી રીતે ફિટ કરવું

ઘણા લોકો PostgreSQL DBMS થી પરિચિત છે, અને તે નાના સ્થાપનોમાં પોતાને સાબિત કરે છે. જો કે, ઓપન સોર્સ તરફનું વલણ વધુને વધુ સ્પષ્ટ બન્યું છે, ભલે તે મોટી કંપનીઓ અને એન્ટરપ્રાઇઝની જરૂરિયાતોની વાત આવે. આ લેખમાં અમે તમને જણાવીશું કે પોસ્ટગ્રેસને કોર્પોરેટ વાતાવરણમાં કેવી રીતે એકીકૃત કરવું અને ઉદાહરણ તરીકે કોમવોલ્ટ બેકઅપ સિસ્ટમનો ઉપયોગ કરીને આ ડેટાબેઝ માટે બેકઅપ સિસ્ટમ (BSS) બનાવવાના અમારા અનુભવને શેર કરીશું.

PostgreSQL પહેલાથી જ તેની યોગ્યતા સાબિત કરી ચૂક્યું છે - DBMS સરસ કામ કરે છે, તેનો ઉપયોગ અલીબાબા અને TripAdvisor જેવા ફેશનેબલ ડિજિટલ વ્યવસાયો દ્વારા કરવામાં આવે છે, અને લાઇસન્સિંગ ફીનો અભાવ તેને MS SQL અથવા Oracle DB જેવા રાક્ષસો માટે આકર્ષક વિકલ્પ બનાવે છે. પરંતુ જલદી અમે એન્ટરપ્રાઇઝ લેન્ડસ્કેપમાં PostgreSQL વિશે વિચારવાનું શરૂ કરીએ છીએ, અમે તરત જ કડક આવશ્યકતાઓમાં દોડી જઈએ છીએ: “કન્ફિગરેશન ફોલ્ટ ટોલરન્સ વિશે શું? આપત્તિ પ્રતિકાર? વ્યાપક દેખરેખ ક્યાં છે? સ્વચાલિત બેકઅપ વિશે શું? ટેપ લાઇબ્રેરીઓનો સીધો અને ગૌણ સ્ટોરેજ પર ઉપયોગ કરવા વિશે શું?


એક તરફ, PostgreSQL પાસે બિલ્ટ-ઇન બેકઅપ ટૂલ્સ નથી, જેમ કે "પુખ્ત" DBMS જેમ કે Oracle DBમાં RMAN અથવા SAP ડેટાબેઝ બેકઅપ. બીજી બાજુ, કોર્પોરેટ બેકઅપ સિસ્ટમ્સ (Veeam, Veritas, Commvault) ના સપ્લાયર્સ, જોકે તેઓ PostgreSQL ને સપોર્ટ કરે છે, હકીકતમાં તેઓ માત્ર ચોક્કસ (સામાન્ય રીતે એકલ) રૂપરેખાંકન અને વિવિધ પ્રતિબંધોના સમૂહ સાથે જ કામ કરે છે.

પોસ્ટગ્રેએસક્યુએલ માટે ખાસ રચાયેલ બેકઅપ સિસ્ટમો, જેમ કે બર્મન, વોલ-જી, પીજી_પ્રોબેકઅપ, પોસ્ટગ્રેએસક્યુએલ ડીબીએમએસના નાના સ્થાપનોમાં અત્યંત લોકપ્રિય છે અથવા જ્યાં IT લેન્ડસ્કેપના અન્ય ઘટકોના ભારે બેકઅપની જરૂર નથી. ઉદાહરણ તરીકે, PostgreSQL ઉપરાંત, ઈન્ફ્રાસ્ટ્રક્ચરમાં ભૌતિક અને વર્ચ્યુઅલ સર્વર્સ, OpenShift, Oracle, MariaDB, Cassandra, વગેરેનો સમાવેશ થઈ શકે છે. સામાન્ય સાધન વડે આ બધાનો બેકઅપ લેવાની સલાહ આપવામાં આવે છે. ફક્ત PostgreSQL માટે અલગ સોલ્યુશન ઇન્સ્ટોલ કરવું એ એક ખરાબ વિચાર છે: ડેટા ક્યાંક ડિસ્ક પર કૉપિ કરવામાં આવશે, અને પછી તેને ટેપમાં દૂર કરવાની જરૂર છે. આ ડબલ બેકઅપ બેકઅપ સમયને વધારે છે, અને વધુ ગંભીર રીતે, પુનઃપ્રાપ્તિ સમય પણ.

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

ડાઉનટાઇમના જોખમને ઘટાડવા માટે, ફોલ્ટ-ટોલરન્ટ સિસ્ટમ બનાવતી વખતે, "લાઇવ" ક્લસ્ટર ગોઠવણી બનાવવામાં આવે છે, અને પ્રાથમિક ધીમે ધીમે વિવિધ સર્વર્સ વચ્ચે સ્થાનાંતરિત થઈ શકે છે. ઉદાહરણ તરીકે, પેટ્રોની સોફ્ટવેર પોતે પ્રાઇમરીને રેન્ડમલી પસંદ કરેલ ક્લસ્ટર નોડ પર લોન્ચ કરે છે. IBS પાસે આને બૉક્સની બહાર ટ્રૅક કરવાનો કોઈ રસ્તો નથી, અને જો રૂપરેખાંકન બદલાય છે, તો પ્રક્રિયાઓ તૂટી જાય છે. એટલે કે, બાહ્ય નિયંત્રણની રજૂઆત ISR ને અસરકારક રીતે કામ કરતા અટકાવે છે, કારણ કે નિયંત્રણ સર્વર ફક્ત સમજી શકતું નથી કે ક્યાં અને કયા ડેટાની નકલ કરવાની જરૂર છે.

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

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

પીછેહઠ કરવા માટે ક્યાંય નથી! મોસ્કો વિકાસકર્તાઓ પાછળ છે!

જો કે, તાજેતરમાં અમારી ટીમને એક મુશ્કેલ પડકારનો સામનો કરવો પડ્યો: AIS OSAGO 2.0 બનાવવાના પ્રોજેક્ટમાં, જ્યાં અમે IT ઇન્ફ્રાસ્ટ્રક્ચર બનાવ્યું હતું, વિકાસકર્તાઓએ નવી સિસ્ટમ માટે PostgreSQL પસંદ કર્યું.

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

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

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

એન્ટરપ્રાઇઝ માટે થોડો જાદુ

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

અમે 3 આંતરિક "હેકાથોન" યોજ્યા - અમે પચાસથી વધુ વિકાસને જોયા, તેનું પરીક્ષણ કર્યું, અમારી પૂર્વધારણાઓના સંબંધમાં ફેરફારો કર્યા અને તેનું ફરીથી પરીક્ષણ કર્યું. ઉપલબ્ધ વિકલ્પોની સમીક્ષા કર્યા પછી, અમે Commvault પસંદ કર્યું. બૉક્સની બહાર, આ પ્રોડક્ટ સૌથી સરળ PostgreSQL ક્લસ્ટર ઇન્સ્ટોલેશન સાથે કામ કરી શકે છે, અને તેના ઓપન આર્કિટેક્ચરે સફળ વિકાસ અને એકીકરણ માટે આશાઓ (જે વાજબી હતી) ઉભી કરી હતી. Commvault પોસ્ટગ્રેએસક્યુએલ લોગનો બેકઅપ પણ લઈ શકે છે. ઉદાહરણ તરીકે, PostgreSQL ના સંદર્ભમાં Veritas NetBackup માત્ર સંપૂર્ણ બેકઅપ બનાવી શકે છે.

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

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

Patroni દરેક ક્લસ્ટર માટે પ્રાથમિક નોડ વ્યાખ્યાયિત કરે છે. તે ડેટા સેન્ટરમાં કોઈપણ મફત નોડ હોઈ શકે છે - પરંતુ માત્ર મોટે ભાગે. બેકઅપમાં, તમામ ગાંઠો ગૌણ છે.

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

સામાન્ય રીતે, પ્રક્રિયા આના જેવી લાગે છે:

Patroni પ્રાથમિક પસંદ કરે છે → Keepalived IP ક્લસ્ટરને પસંદ કરે છે અને સ્ક્રિપ્ટ ચલાવે છે → પસંદ કરેલ ક્લસ્ટર નોડ પર Commvault એજન્ટને સૂચના પ્રાપ્ત થાય છે કે આ પ્રાથમિક છે → Commvault સ્યુડો-ક્લાયન્ટની અંદર બેકઅપને આપમેળે ફરીથી ગોઠવે છે.

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

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

દરેક સ્યુડો-ક્લાયન્ટની અંદર, ક્લસ્ટરનો સક્રિય નોડ સૂચવવામાં આવે છે. Commvault માટે અમારું એકીકરણ ઉકેલ આ વ્યાખ્યાયિત કરે છે. તેની કામગીરીનો સિદ્ધાંત એકદમ સરળ છે: જો નોડ પર ક્લસ્ટર IP ઉભા કરવામાં આવે છે, તો સ્ક્રિપ્ટ કોમવૉલ્ટ એજન્ટ બાઈનરીમાં "સક્રિય નોડ" પરિમાણ સેટ કરે છે - હકીકતમાં, સ્ક્રિપ્ટ મેમરીના જરૂરી ભાગમાં "1" સેટ કરે છે. . એજન્ટ આ ડેટાને CommServe પર ટ્રાન્સમિટ કરે છે, અને Commvault ઇચ્છિત નોડમાંથી બેકઅપ બનાવે છે. વધુમાં, રૂપરેખાંકનની શુદ્ધતા સ્ક્રિપ્ટ સ્તરે તપાસવામાં આવે છે, બેકઅપ શરૂ કરતી વખતે ભૂલોને ટાળવામાં મદદ કરે છે.

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

બાય ધ વે, અમે PostgreSQL આર્કાઇવ લૉગ્સનો બેકઅપ લેવા માટે અલગ નીતિઓ લાગુ કરી છે - તે અલગ-અલગ નિયમો અનુસાર સ્ટોર કરવામાં આવે છે, અલગ શેડ્યૂલ અનુસાર કૉપિ કરવામાં આવે છે અને તેમના માટે ડિડુપ્લિકેશન સક્ષમ નથી, કારણ કે આ લૉગ્સમાં અનન્ય ડેટા હોય છે.

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

હાલમાં, IBS ઉત્પાદકતા સેવાઓને અસર કરતું નથી, પરંતુ જો પરિસ્થિતિ બદલાય છે, તો Commvault લોડ મર્યાદાને સક્ષમ કરી શકે છે.

શું તે સારું છે? સારું!

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

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

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

શું તમે કોર્પોરેટ વાતાવરણમાં PostgreSQL સાથે કામ કરવાનો પ્રયાસ કર્યો છે?

લેખકો:

ઓલેગ લવરેનોવ, ડેટા સ્ટોરેજ સિસ્ટમ્સના ડિઝાઇન એન્જિનિયર, જેટ ઇન્ફોસિસ્ટમ્સ

દિમિત્રી એરિકિન, જેટ ઇન્ફોસિસ્ટમ્સમાં કમ્પ્યુટર સિસ્ટમ્સના ડિઝાઇન એન્જિનિયર

સોર્સ: www.habr.com