గత సంవత్సరం చివరలో, రష్యన్ PostgreSQL సంఘం యొక్క మరొక ప్రత్యక్ష ప్రసారం జరిగింది , దాని సహ వ్యవస్థాపకుడు నికోలాయ్ సమోఖ్వలోవ్ ఈ DBMS గురించి కుబెర్నెటెస్ సందర్భంలో ఫ్లాంట్ టెక్నికల్ డైరెక్టర్ డిమిత్రి స్టోలియారోవ్‌తో మాట్లాడారు.
మేము ఈ చర్చ యొక్క ప్రధాన భాగం యొక్క ట్రాన్స్క్రిప్ట్ను ప్రచురిస్తున్నాము మరియు ఇక్కడ పూర్తి వీడియో పోస్ట్ చేయబడింది:
డేటాబేస్‌లు మరియు కుబెర్నెట్స్
NS: మేము ఈ రోజు వాక్యూమ్ మరియు చెక్‌పాయింట్‌ల గురించి మాట్లాడము. మేము కుబెర్నెట్స్ గురించి మాట్లాడాలనుకుంటున్నాము. మీకు చాలా సంవత్సరాల అనుభవం ఉందని నాకు తెలుసు. నేను మీ వీడియోలను చూశాను మరియు వాటిలో కొన్నింటిని మళ్లీ చూశాను... నేరుగా పాయింట్‌కి వద్దాం: K8sలో Postgres లేదా MySQL ఎందుకు?
DS: ఈ ప్రశ్నకు ఖచ్చితమైన సమాధానం లేదు మరియు ఉండకూడదు. కానీ సాధారణంగా, ఇది సరళత మరియు సౌలభ్యం ... సంభావ్యత. ప్రతి ఒక్కరూ నిర్వహించబడే సేవలను కోరుకుంటున్నారు.
NS: ఎలా , ఇంట్లో మాత్రమేనా?
DS: అవును: RDS లాగా, ఎక్కడైనా.
NS: "ఎనీవేర్" అనేది మంచి పాయింట్. పెద్ద కంపెనీలలో, ప్రతిదీ వేర్వేరు ప్రదేశాలలో ఉంది. పెద్ద కంపెనీ అయితే రెడీమేడ్ సొల్యూషన్ ఎందుకు తీసుకోరు? ఉదాహరణకు, Nutanix దాని స్వంత అభివృద్ధిని కలిగి ఉంది, ఇతర కంపెనీలు (VMware...) అదే "RDS, ఇంట్లో మాత్రమే" కలిగి ఉన్నాయి.
DS: కానీ మేము కొన్ని పరిస్థితులలో మాత్రమే పని చేసే ప్రత్యేక అమలు గురించి మాట్లాడుతున్నాము. మరియు మేము కుబెర్నెట్స్ గురించి మాట్లాడుతుంటే, భారీ రకాల మౌలిక సదుపాయాలు ఉన్నాయి (ఇది K8 లలో ఉండవచ్చు). ముఖ్యంగా ఇది క్లౌడ్‌కి APIలకు ప్రమాణం...
NS: ఇది కూడా ఉచితం!
DS: ఇది అంత ముఖ్యమైనది కాదు. మార్కెట్‌లోని చాలా పెద్ద సెగ్మెంట్‌కు స్వేచ్ఛ ముఖ్యం. ఇంకేదైనా ముఖ్యమైనది... మీరు బహుశా నివేదికను గుర్తుంచుకుంటారు “"?
NS: అవును.
DS: ఇది చాలా సందిగ్ధంగా స్వీకరించబడిందని నేను గ్రహించాను. కొంతమంది నేను ఇలా చెబుతున్నానని అనుకున్నారు: “అబ్బాయిలు, అన్ని డేటాబేస్‌లను కుబెర్నెట్స్‌లోకి చేద్దాం!”, మరికొందరు ఇవన్నీ భయంకరమైన సైకిళ్లే అని నిర్ణయించుకున్నారు. కానీ నేను పూర్తిగా భిన్నమైన విషయం చెప్పాలనుకుంటున్నాను: “ఏమి జరుగుతుందో చూడండి, ఏ సమస్యలు ఉన్నాయి మరియు వాటిని ఎలా పరిష్కరించవచ్చో చూడండి. మేము ఇప్పుడు Kubernetes డేటాబేస్‌లను ఉపయోగించాలా? ఉత్పత్తి? సరే, మీకు నచ్చితేనే... కొన్ని పనులు చేయడం. కానీ దేవ్ కోసం, నేను దీన్ని సిఫార్సు చేస్తున్నాను అని చెప్పగలను. దేవ్ కోసం, వాతావరణాలను సృష్టించడం/తొలగించడంలో చైతన్యం చాలా ముఖ్యం.
NS: దేవ్ ద్వారా, మీరు ప్రోద్ చేయని అన్ని వాతావరణాలను సూచిస్తున్నారా? స్టేజింగ్, QA…
DS: మనం పెర్ఫ్ స్టాండ్‌ల గురించి మాట్లాడుతున్నట్లయితే, బహుశా కాదు, ఎందుకంటే అక్కడ అవసరాలు నిర్దిష్టంగా ఉంటాయి. స్టేజింగ్ కోసం చాలా పెద్ద డేటాబేస్ అవసరమయ్యే ప్రత్యేక సందర్భాల గురించి మనం మాట్లాడుతుంటే, బహుశా కాదు... ఇది స్థిరమైన, దీర్ఘకాలిక వాతావరణం అయితే, డేటాబేస్ K8 లలో ఉండటం వల్ల ప్రయోజనం ఏమిటి?
NS: ఏదీ లేదు. కానీ స్థిర వాతావరణాలను మనం ఎక్కడ చూస్తాము? స్థిరమైన వాతావరణం రేపు వాడుకలో ఉండదు.
DS: స్టేజింగ్ స్థిరంగా ఉంటుంది. మాకు క్లయింట్లు ఉన్నారు...
NS: అవును, నా దగ్గర కూడా ఒకటి ఉంది. మీకు 10 TB డేటాబేస్ మరియు 200 GB స్టేజింగ్ ఉంటే అది పెద్ద సమస్య...
DS: నాకు చాలా మంచి కేసు ఉంది! ప్రదర్శనలో మార్పులు చేసిన ఉత్పత్తి డేటాబేస్ ఉంది. మరియు ఒక బటన్ ఉంది: "ఉత్పత్తికి వెళ్లండి". ఈ మార్పులు - డెల్టాలు - ఉత్పత్తిలో జోడించబడ్డాయి (అవి కేవలం API ద్వారా సమకాలీకరించబడినట్లు అనిపిస్తుంది). ఇది చాలా అన్యదేశ ఎంపిక.
NS: నేను లోయలో RDSలో లేదా హీరోకులో కూర్చున్న స్టార్టప్‌లను చూశాను - ఇవి 2-3 సంవత్సరాల క్రితం కథలు - మరియు వారు తమ ల్యాప్‌టాప్‌కు డంప్‌ను డౌన్‌లోడ్ చేసుకుంటారు. ఎందుకంటే డేటాబేస్ ఇప్పటికీ 80 GB మాత్రమే, మరియు ల్యాప్‌టాప్‌లో స్థలం ఉంది. అప్పుడు వారు ప్రతి ఒక్కరికీ అదనపు డిస్క్‌లను కొనుగోలు చేస్తారు, తద్వారా వివిధ అభివృద్ధిని నిర్వహించడానికి వారికి 3 డేటాబేస్‌లు ఉంటాయి. ఇది కూడా ఇలాగే జరుగుతుంది. ఉత్పత్తిని స్టేజింగ్‌లోకి కాపీ చేయడానికి వారు భయపడరని కూడా నేను చూశాను - ఇది చాలా కంపెనీపై ఆధారపడి ఉంటుంది. కానీ వారు చాలా భయపడుతున్నారని మరియు వారికి తరచుగా తగినంత సమయం మరియు చేతులు ఉండవని నేను కూడా చూశాను. కానీ మనం ఈ అంశానికి వెళ్లే ముందు, నేను కుబెర్నెట్స్ గురించి వినాలనుకుంటున్నాను. ఇంకా ఎవరూ పనిలో లేరని నేను సరిగ్గా అర్థం చేసుకున్నానా?
DS: మేము ఉత్పత్తిలో చిన్న డేటాబేస్‌లను కలిగి ఉన్నాము. మేము పదుల గిగాబైట్‌ల వాల్యూమ్‌లు మరియు నాన్-క్రిటికల్ సర్వీస్‌ల గురించి మాట్లాడుతున్నాము, దీని కోసం మేము ప్రతిరూపాలను తయారు చేయడానికి చాలా సోమరిగా ఉన్నాము (మరియు అలాంటి అవసరం లేదు). మరియు Kubernetes కింద సాధారణ నిల్వ ఉంది అందించిన. ఈ డేటాబేస్ వర్చువల్ మెషీన్‌లో పని చేస్తుంది - షరతులతో VMwareలో, నిల్వ సిస్టమ్ పైన. మేము దానిని ఉంచాము మరియు ఇప్పుడు మనం దానిని యంత్రం నుండి యంత్రానికి బదిలీ చేయవచ్చు.
NS: ఈ పరిమాణంలో, 100 GB వరకు ఉన్న డేటాబేస్‌లు, మంచి డిస్క్‌లు మరియు మంచి నెట్‌వర్క్‌లో కొన్ని నిమిషాల్లో విడుదల చేయబడతాయి, సరియైనదా? సెకనుకు 1 GB వేగం ఇకపై అన్యదేశమైనది కాదు.
DS: అవును, లీనియర్ ఆపరేషన్ కోసం ఇది సమస్య కాదు.
NS: సరే, మనం ఉత్పత్తి గురించి ఆలోచించాలి. మరియు మేము నాన్-ప్రోడ్ ఎన్విరాన్మెంట్ల కోసం కుబెర్నెట్‌లను పరిశీలిస్తున్నట్లయితే, మనం ఏమి చేయాలి? నేను జలాండోలో చూస్తున్నాను , క్రంచీలో , కొన్ని ఇతర ఎంపికలు ఉన్నాయి. మరియు ఉంది - ఇది స్పెయిన్‌కు చెందిన మా మంచి స్నేహితుడు అల్వారో: వారు చేసేది కేవలం కాదు , మరియు మొత్తం పంపిణీ (), దీనిలో, పోస్ట్‌గ్రెస్‌తో పాటు, వారు బ్యాకప్, ఎన్వాయ్ ప్రాక్సీని కూడా నింపాలని నిర్ణయించుకున్నారు...
DS: దేనికి దూత? పోస్ట్‌గ్రెస్ ట్రాఫిక్‌ని ప్రత్యేకంగా బ్యాలెన్స్ చేస్తున్నారా?
NS: అవును. అంటే, వారు దానిని ఇలా చూస్తారు: మీరు Linux పంపిణీ మరియు కెర్నల్‌ని తీసుకుంటే, సాధారణ PostgreSQL కెర్నల్, మరియు వారు క్లౌడ్-స్నేహపూర్వకంగా మరియు కుబెర్నెట్స్‌లో రన్ అయ్యే పంపిణీని చేయాలనుకుంటున్నారు. వారు భాగాలను (బ్యాకప్‌లు మొదలైనవి) ఒకచోట చేర్చారు మరియు వాటిని డీబగ్ చేస్తారు, తద్వారా అవి బాగా పని చేస్తాయి.
DS: చాలా బాగుంది! ముఖ్యంగా ఇది మీ స్వంతంగా నిర్వహించబడే పోస్ట్‌గ్రెస్‌ని సృష్టించడానికి సాఫ్ట్‌వేర్.
NS: Linux పంపిణీలకు శాశ్వతమైన సమస్యలు ఉన్నాయి: అన్ని హార్డ్‌వేర్‌లకు మద్దతు ఇచ్చేలా డ్రైవర్‌లను ఎలా తయారు చేయాలి. మరియు వారు కుబెర్నెట్స్‌లో పని చేస్తారనే ఆలోచన ఉంది. Zalando ఆపరేటర్‌లో మేము ఇటీవల AWSకి కనెక్షన్‌ని చూశాము మరియు ఇది చాలా మంచిది కాదని నాకు తెలుసు. నిర్దిష్ట మౌలిక సదుపాయాలతో ముడిపెట్టకూడదు - అప్పుడు ప్రయోజనం ఏమిటి?
DS: జలాండో ఏ పరిస్థితిలో చిక్కుకుందో నాకు సరిగ్గా తెలియదు, కానీ కుబెర్నెటెస్ నిల్వలో ఇప్పుడు సాధారణ పద్ధతిని ఉపయోగించి డిస్క్ బ్యాకప్ తీసుకోవడం సాధ్యం కాని విధంగా తయారు చేయబడింది. ఇటీవల స్టాండర్డ్‌లో - తాజా వెర్షన్‌లో — మేము స్నాప్‌షాట్‌లను సాధ్యం చేసాము, అయితే ఇది ఎక్కడ అమలు చేయబడింది? నిజాయితీగా, ప్రతిదీ ఇప్పటికీ చాలా పచ్చిగా ఉంది... మేము AWS, GCE, Azure, vSphere పైన CSIని ప్రయత్నిస్తున్నాము, కానీ మీరు దీన్ని ఉపయోగించడం ప్రారంభించిన వెంటనే, ఇది ఇంకా సిద్ధంగా లేదని మీరు చూడవచ్చు.
NS: అందుకే మనం కొన్నిసార్లు మౌలిక సదుపాయాలపై ఆధారపడవలసి వస్తుంది. ఇది ఇప్పటికీ ప్రారంభ దశ అని నేను అనుకుంటున్నాను - పెరుగుతున్న నొప్పులు. ప్రశ్న: K8sలో PgSQLని ప్రయత్నించాలనుకునే కొత్తవారికి మీరు ఏ సలహా ఇస్తారు? ఏ ఆపరేటర్ కావచ్చు?
DS: సమస్య ఏమిటంటే పోస్ట్‌గ్రెస్ మాకు 3%. మేము కుబెర్నెట్స్‌లో విభిన్న సాఫ్ట్‌వేర్‌ల యొక్క చాలా పెద్ద జాబితాను కూడా కలిగి ఉన్నాము, నేను ప్రతిదీ కూడా జాబితా చేయను. ఉదాహరణకు, సాగే శోధన. చాలా మంది ఆపరేటర్లు ఉన్నారు: కొందరు చురుకుగా అభివృద్ధి చెందుతున్నారు, ఇతరులు లేరు. మేము మా కోసం అవసరాలను రూపొందించాము, ఆపరేటర్‌లో ఏమి ఉండాలి కాబట్టి మేము దానిని తీవ్రంగా పరిగణిస్తాము. ప్రత్యేకంగా Kubernetes కోసం ఒక ఆపరేటర్‌లో - “Amazon పరిస్థితులలో ఏదైనా చేయడానికి ఆపరేటర్”లో కాదు... వాస్తవానికి, మేము చాలా విస్తృతంగా (= దాదాపు అన్ని క్లయింట్లు) ఒకే ఆపరేటర్‌ని ఉపయోగిస్తాము - (త్వరలో ఆయన గురించిన కథనాన్ని ప్రచురిస్తాము).
NS: మరియు MySQL కోసం కాదా? పెర్కోనా అని నాకు తెలుసు... వారు ఇప్పుడు MySQL, MongoDB మరియు Postgresలో పని చేస్తున్నారు కాబట్టి, వారు ఒక రకమైన యూనివర్సల్ సొల్యూషన్‌ను సృష్టించాలి: అన్ని డేటాబేస్‌ల కోసం, క్లౌడ్ ప్రొవైడర్లందరికీ.
DS: MySQL కోసం ఆపరేటర్‌లను చూసేందుకు మాకు సమయం లేదు. ఇది ప్రస్తుతం మా ప్రధాన దృష్టి కాదు. MySQL స్వతంత్రంగా బాగా పనిచేస్తుంది. మీరు డేటాబేస్ను ప్రారంభించగలిగితే ఆపరేటర్‌ను ఎందుకు ఉపయోగించాలి... మీరు పోస్టర్‌జెస్‌తో డాకర్ కంటైనర్‌ను ప్రారంభించవచ్చు లేదా మీరు దానిని సరళమైన మార్గంలో ప్రారంభించవచ్చు.
NS: దీని గురించి కూడా ఒక ప్రశ్న వచ్చింది. ఆపరేటర్ లేరా?
DS: అవును, మనలో 100% PostgreSQL ఆపరేటర్ లేకుండా రన్ అవుతోంది. ఇప్పటి వరకు. మేము ప్రోమేతియస్ మరియు రెడిస్ కోసం ఆపరేటర్‌ను చురుకుగా ఉపయోగిస్తాము. ఎలాస్టిక్‌సెర్చ్ కోసం ఆపరేటర్‌ని కనుగొనడానికి మేము ప్లాన్‌లు కలిగి ఉన్నాము - ఇది చాలా “అగ్నిలో” ఉంది, ఎందుకంటే మేము దీనిని 100% కేసులలో కుబెర్నెట్స్‌లో ఇన్‌స్టాల్ చేయాలనుకుంటున్నాము. మేము MongoDB కూడా ఎల్లప్పుడూ Kubernetes లో ఇన్‌స్టాల్ చేయబడి ఉండేలా చూడాలనుకుంటున్నాము. ఇక్కడ కొన్ని కోరికలు కనిపిస్తాయి - ఈ సందర్భాలలో ఏదైనా చేయవచ్చనే భావన ఉంది. మరియు మేము పోస్ట్‌గ్రెస్‌ని కూడా చూడలేదు. వాస్తవానికి, విభిన్న ఎంపికలు ఉన్నాయని మాకు తెలుసు, కానీ వాస్తవానికి మనకు స్వతంత్రం ఉంది.
కుబెర్నెట్స్‌లో పరీక్ష కోసం DB
NS: పరీక్ష అనే అంశానికి వెళ్దాం. డేటాబేస్‌లో మార్పులను ఎలా రూపొందించాలి - DevOps కోణం నుండి. మైక్రోసర్వీస్‌లు ఉన్నాయి, చాలా డేటాబేస్‌లు ఉన్నాయి, నిత్యం ఎక్కడో ఏదో ఒకచోట మారుతూ ఉంటాయి. DBMS దృక్కోణం నుండి ప్రతిదీ క్రమంలో ఉండేలా సాధారణ CI/CDని ఎలా నిర్ధారించాలి. మీ విధానం ఏమిటి?
DS: ఒక్క సమాధానం ఉండకూడదు. అనేక ఎంపికలు ఉన్నాయి. మొదటిది మనం బయటకు వెళ్లాలనుకుంటున్న బేస్ పరిమాణం. డెవ్ మరియు స్టేజ్‌లో ప్రోడ్ డేటాబేస్ కాపీని కలిగి ఉండటం పట్ల కంపెనీలు భిన్నమైన వైఖరిని కలిగి ఉన్నాయని మీరే పేర్కొన్నారు.
NS: మరియు GDPR యొక్క పరిస్థితులలో, వారు మరింత జాగ్రత్తగా ఉన్నారని నేను భావిస్తున్నాను... ఐరోపాలో వారు ఇప్పటికే జరిమానాలు విధించడం ప్రారంభించారని నేను చెప్పగలను.
DS: కానీ తరచుగా మీరు ఉత్పత్తి నుండి డంప్ తీసుకొని దానిని అస్పష్టం చేసే సాఫ్ట్‌వేర్‌ను వ్రాయవచ్చు. ఉత్పత్తి డేటా పొందబడింది (స్నాప్‌షాట్, డంప్, బైనరీ కాపీ...), కానీ అది అనామకంగా ఉంది. బదులుగా, జనరేషన్ స్క్రిప్ట్‌లు ఉండవచ్చు: ఇవి ఫిక్చర్‌లు కావచ్చు లేదా పెద్ద డేటాబేస్ను రూపొందించే స్క్రిప్ట్ కావచ్చు. సమస్య ఏమిటంటే: బేస్ ఇమేజ్‌ని రూపొందించడానికి ఎంత సమయం పడుతుంది? మరియు దానిని కావలసిన వాతావరణంలో అమర్చడానికి ఎంత సమయం పడుతుంది?
మేము ఒక స్కీమ్‌కి వచ్చాము: క్లయింట్ స్థిర డేటా సెట్‌ను కలిగి ఉంటే (డేటాబేస్ యొక్క కనిష్ట వెర్షన్), అప్పుడు మేము వాటిని డిఫాల్ట్‌గా ఉపయోగిస్తాము. మేము సమీక్ష పరిసరాల గురించి మాట్లాడుతున్నట్లయితే, మేము ఒక శాఖను సృష్టించినప్పుడు, మేము అప్లికేషన్ యొక్క ఉదాహరణను అమలు చేసాము - మేము అక్కడ ఒక చిన్న డేటాబేస్ను రూపొందిస్తాము. కానీ అది బాగానే మారింది , మేము రోజుకు ఒకసారి (రాత్రి సమయంలో) ఉత్పత్తి నుండి డంప్ తీసుకున్నప్పుడు మరియు దాని ఆధారంగా ఈ లోడ్ చేయబడిన డేటాతో PostgreSQL మరియు MySQLతో డాకర్ కంటైనర్‌ను రూపొందించినప్పుడు. మీరు ఈ చిత్రం నుండి డేటాబేస్ను 50 సార్లు విస్తరించాల్సిన అవసరం ఉంటే, ఇది చాలా సరళంగా మరియు త్వరగా చేయబడుతుంది.
NS: సాధారణ కాపీ చేయడం ద్వారా?
DS: డేటా నేరుగా డాకర్ చిత్రంలో నిల్వ చేయబడుతుంది. ఆ. మేము 100 GB అయినప్పటికీ, రెడీమేడ్ ఇమేజ్‌ని కలిగి ఉన్నాము. డాకర్‌లోని లేయర్‌లకు ధన్యవాదాలు, ఈ చిత్రాన్ని మనకు అవసరమైనన్ని సార్లు త్వరగా అమర్చవచ్చు. పద్ధతి తెలివితక్కువది, కానీ ఇది బాగా పనిచేస్తుంది.
NS: అప్పుడు, మీరు పరీక్షించినప్పుడు, అది డాకర్‌లోనే మారుతుంది, సరియైనదా? డాకర్ లోపల కాపీ-ఆన్-రైట్ - దాన్ని విసిరివేసి మళ్లీ వెళ్లండి, అంతా బాగానే ఉంది. తరగతి! మరియు మీరు దీన్ని ఇప్పటికే పూర్తి స్థాయిలో ఉపయోగిస్తున్నారా?
DS: చాలా కాలం వరకు.
NS: మేము చాలా సారూప్యమైన పనులు చేస్తాము. మేము మాత్రమే డాకర్ యొక్క కాపీ-ఆన్-రైట్‌ని ఉపయోగించము, కానీ మరొకటి.
DS: ఇది సాధారణమైనది కాదు. మరియు డాకర్ ప్రతిచోటా పని చేస్తుంది.
NS: సిద్ధాంతపరంగా, అవును. కానీ మాకు అక్కడ మాడ్యూల్స్ కూడా ఉన్నాయి, మీరు వేర్వేరు మాడ్యూళ్ళను తయారు చేయవచ్చు మరియు వివిధ ఫైల్ సిస్టమ్‌లతో పని చేయవచ్చు. ఇక్కడ ఒక క్షణం. పోస్ట్‌గ్రెస్ వైపు నుండి, మేము ఇవన్నీ భిన్నంగా చూస్తాము. ఇప్పుడు నేను డాకర్ వైపు నుండి చూసాను మరియు ప్రతిదీ మీ కోసం పని చేస్తుందని చూశాను. డేటాబేస్ భారీగా ఉంటే, ఉదాహరణకు, 1 TB, అప్పుడు ఇదంతా చాలా సమయం పడుతుంది: రాత్రి ఆపరేషన్లు మరియు డాకర్‌లో ప్రతిదీ నింపడం... మరియు 5 TB డాకర్‌లో నింపబడితే... లేదా అంతా బాగానే ఉందా?
DS: తేడా ఏమిటి: ఇవి బొట్టు, కేవలం బిట్‌లు మరియు బైట్‌లు.
NS: తేడా ఇది: మీరు దీన్ని డంప్ మరియు రీస్టోర్ ద్వారా చేస్తారా?
DS: అవసరం లేదు. ఈ చిత్రాన్ని రూపొందించే పద్ధతులు భిన్నంగా ఉండవచ్చు.
NS: కొంతమంది క్లయింట్‌ల కోసం, మేము దీన్ని తయారు చేసాము, తద్వారా క్రమం తప్పకుండా బేస్ ఇమేజ్‌ని రూపొందించడానికి బదులుగా, మేము దానిని నిరంతరం తాజాగా ఉంచుతాము. ఇది తప్పనిసరిగా ప్రతిరూపం, కానీ ఇది మాస్టర్ నుండి నేరుగా కాకుండా ఆర్కైవ్ ద్వారా డేటాను అందుకుంటుంది. ప్రతిరోజు WALలు డౌన్‌లోడ్ చేయబడే బైనరీ ఆర్కైవ్, ఇక్కడ బ్యాకప్‌లు తీసుకోబడతాయి... ఈ WALలు కొంచెం ఆలస్యంతో (అక్షరాలా 1-2 సెకన్లు) బేస్ ఇమేజ్‌కి చేరుకుంటాయి. మేము దాని నుండి ఏ విధంగానైనా క్లోన్ చేస్తాము - ఇప్పుడు మనకు డిఫాల్ట్‌గా ZFS ఉంది.
DS: కానీ ZFSతో మీరు ఒక నోడ్‌కి పరిమితం చేయబడతారు.
NS: అవును. కానీ ZFSలో మాయాజాలం కూడా ఉంది : దీనితో మీరు స్నాప్‌షాట్‌ను పంపవచ్చు మరియు (నేను దీన్ని ఇంకా పరీక్షించలేదు, కానీ...) మీరు రెండింటి మధ్య డెల్టాను పంపవచ్చు PGDATA. వాస్తవానికి, అటువంటి పనుల కోసం మేము నిజంగా పరిగణించని మరొక సాధనాన్ని కలిగి ఉన్నాము. PostgreSQL ఉంది , ఇది "స్మార్ట్" rsync లాగా పనిచేస్తుంది, మీరు చూడాల్సిన అవసరం లేని చాలా వాటిని దాటవేస్తుంది, ఎందుకంటే అక్కడ ఏమీ మారలేదు. మేము రెండు సర్వర్‌ల మధ్య శీఘ్ర సమకాలీకరణను చేయవచ్చు మరియు అదే విధంగా రివైండ్ చేయవచ్చు.
కాబట్టి, దీని నుండి, మరింత DBA వైపు, మేము మీరు చెప్పిన అదే పనిని చేయడానికి అనుమతించే సాధనాన్ని రూపొందించడానికి ప్రయత్నిస్తున్నాము: మా వద్ద ఒక డేటాబేస్ ఉంది, కానీ మేము దాదాపు ఏకకాలంలో ఏదైనా 50 సార్లు పరీక్షించాలనుకుంటున్నాము.
DS: 50 సార్లు అంటే మీరు 50 స్పాట్ ఇన్‌స్టాన్స్‌లను ఆర్డర్ చేయాలి.
NS: లేదు, మేము ప్రతిదీ ఒకే మెషీన్‌లో చేస్తాము.
DS: అయితే ఈ ఒక్క డేటాబేస్ టెరాబైట్ అయితే మీరు 50 రెట్లు ఎలా విస్తరింపజేస్తారు. ఆమెకు షరతులతో కూడిన 256 GB RAM అవసరమా?
NS: అవును, కొన్నిసార్లు మీకు చాలా మెమరీ అవసరం - అది సాధారణం. కానీ ఇది జీవితం నుండి ఒక ఉదాహరణ. ఉత్పత్తి యంత్రంలో 96 కోర్లు మరియు 600 GB ఉన్నాయి. అదే సమయంలో, డేటాబేస్ కోసం 32 కోర్లు (ఇప్పుడు కొన్నిసార్లు 16 కోర్లు కూడా) మరియు 100-120 GB మెమరీ ఉపయోగించబడతాయి.
DS: మరియు అక్కడ 50 కాపీలు సరిపోతాయా?
NS: కాబట్టి ఒక కాపీ మాత్రమే ఉంది, ఆపై కాపీ-ఆన్-రైట్ (ZFS) పనిచేస్తుంది... నేను మీకు మరింత వివరంగా చెబుతాను.
ఉదాహరణకు, మనకు 10 TB డేటాబేస్ ఉంది. వారు దాని కోసం ఒక డిస్క్‌ను తయారు చేసారు, ZFS దాని పరిమాణాన్ని 30-40 శాతం కుదించింది. మేము లోడ్ పరీక్ష చేయనందున, ఖచ్చితమైన ప్రతిస్పందన సమయం మాకు ముఖ్యం కాదు: ఇది 2 రెట్లు నెమ్మదిగా ఉండనివ్వండి - అది సరే.
మేము ప్రోగ్రామర్లు, QA, DBA మొదలైన వాటికి అవకాశం కల్పిస్తాము. 1-2 థ్రెడ్‌లలో పరీక్ష నిర్వహించండి. ఉదాహరణకు, వారు ఒక రకమైన వలసలను అమలు చేయవచ్చు. దీనికి ఒకేసారి 10 కోర్లు అవసరం లేదు - దీనికి 1 పోస్ట్‌గ్రెస్ బ్యాకెండ్, 1 కోర్ అవసరం. వలస ప్రారంభమవుతుంది - బహుశా ఇప్పటికీ ప్రారంభమవుతుంది, అప్పుడు రెండవ కోర్ ఉపయోగించబడుతుంది. మాకు 16-32 కోర్లు కేటాయించబడ్డాయి, కాబట్టి 10 మంది వ్యక్తులు ఒకే సమయంలో పని చేయవచ్చు, సమస్య లేదు.
ఎందుకంటే భౌతికంగా PGDATA అదే, మేము నిజానికి పోస్ట్‌గ్రెస్‌ని మోసం చేస్తున్నామని తేలింది. ఉపాయం ఇది: ఉదాహరణకు, 10 పోస్ట్‌గ్రెస్‌లు ఏకకాలంలో ప్రారంభించబడ్డాయి. సాధారణంగా సమస్య ఏమిటి? వారు ఉంచారు , 25% అనుకుందాం. దీని ప్రకారం, ఇది 200 GB. మీరు వీటిలో మూడు కంటే ఎక్కువ లాంచ్ చేయలేరు, ఎందుకంటే మెమరీ అయిపోతుంది.
కానీ ఏదో ఒక సమయంలో ఇది అవసరం లేదని మేము గ్రహించాము: మేము షేర్డ్_బఫర్‌లను 2 GBకి సెట్ చేసాము. PostgreSQL ఉంది , మరియు వాస్తవానికి ఇది ప్రభావితం చేసేది ఒక్కటే . మేము దానిని 0,5 TBకి సెట్ చేసాము. మరియు అవి వాస్తవానికి ఉనికిలో లేవని కూడా పట్టింపు లేదు: అతను ఉన్నట్లుగా ప్రణాళికలు వేస్తాడు.
దీని ప్రకారం, మేము ఒక రకమైన వలసలను పరీక్షించినప్పుడు, మేము అన్ని ప్రణాళికలను సేకరించవచ్చు - ఉత్పత్తిలో ఇది ఎలా జరుగుతుందో మేము చూస్తాము. సెకనులు భిన్నంగా ఉంటాయి (నెమ్మదిగా), కానీ మనం నిజంగా చదివే డేటా, మరియు ప్లాన్‌లు (ఏవి చేరి ఉన్నాయి, మొదలైనవి) ఉత్పత్తిలో సరిగ్గా అదే విధంగా ఉంటాయి. మరియు మీరు ఒక మెషీన్‌లో సమాంతరంగా ఇటువంటి అనేక తనిఖీలను అమలు చేయవచ్చు.
DS: ఇక్కడ కొన్ని సమస్యలు ఉన్నాయని మీరు అనుకోలేదా? మొదటిది PostgreSQLలో మాత్రమే పనిచేసే పరిష్కారం. ఈ విధానం చాలా ప్రైవేట్, ఇది సాధారణమైనది కాదు. రెండవది, కుబెర్నెటెస్ (మరియు ఇప్పుడు క్లౌడ్ టెక్నాలజీలు చేయబోయే ప్రతిదీ) అనేక నోడ్‌లను కలిగి ఉంటుంది మరియు ఈ నోడ్‌లు అశాశ్వతమైనవి. మరియు మీ విషయంలో ఇది ఒక రాష్ట్రీయమైన, నిరంతర నోడ్. ఈ విషయాలు నన్ను సంఘర్షణకు గురిచేస్తున్నాయి.
NS: మొదట, నేను అంగీకరిస్తున్నాను, ఇది పూర్తిగా పోస్ట్‌గ్రెస్ కథ. దాదాపు అన్ని మెమరీకి మనకు ప్రత్యక్ష IO మరియు బఫర్ పూల్ ఉన్నట్లయితే, ఈ విధానం పనిచేయదు - ప్రణాళికలు భిన్నంగా ఉంటాయి. కానీ ప్రస్తుతానికి మేము పోస్ట్‌గ్రెస్‌తో మాత్రమే పని చేస్తాము, మేము ఇతరుల గురించి ఆలోచించము.
కుబెర్నెట్స్ గురించి. మాకు నిరంతర డేటాబేస్ ఉందని మీరే ప్రతిచోటా మాకు చెప్పండి. ఉదాహరణ విఫలమైతే, డిస్క్‌ను సేవ్ చేయడం ప్రధాన విషయం. ఇక్కడ మేము కుబెర్నెటెస్‌లో మొత్తం ప్లాట్‌ఫారమ్‌ని కూడా కలిగి ఉన్నాము మరియు పోస్ట్‌గ్రెస్‌తో ఉన్న భాగం వేరుగా ఉంటుంది (అది ఒకరోజు ఉంటుంది). అందువల్ల, ప్రతిదీ ఇలా ఉంటుంది: ఉదాహరణ పడిపోయింది, కానీ మేము దాని PVని సేవ్ చేసాము మరియు ఏమీ జరగనట్లుగా మరొక (కొత్త) ఉదాహరణకి కనెక్ట్ చేసాము.
DS: నా దృక్కోణం నుండి, మేము కుబెర్నెట్స్‌లో పాడ్‌లను సృష్టిస్తాము. K8s - సాగే: నాట్లు అవసరమైన విధంగా ఆర్డర్ చేయబడతాయి. పని కేవలం పాడ్‌ను సృష్టించడం మరియు దానికి X మొత్తంలో వనరులు అవసరమని చెప్పడం, ఆపై K8 లు దానిని స్వయంగా గుర్తించడం. కానీ కుబెర్నెట్స్‌లో నిల్వ మద్దతు ఇప్పటికీ అస్థిరంగా ఉంది: లో (ఈ విడుదల విడుదలైంది недели క్రితం) ఈ లక్షణాలు బీటాగా మాత్రమే మారాయి.
ఆరు నెలల నుండి ఒక సంవత్సరం గడిచిపోతుంది - ఇది ఎక్కువ లేదా తక్కువ స్థిరంగా మారుతుంది, లేదా కనీసం అది ప్రకటించబడుతుంది. అప్పుడు స్నాప్‌షాట్‌లు మరియు పునఃపరిమాణం యొక్క అవకాశం మీ సమస్యను పూర్తిగా పరిష్కరిస్తుంది. ఎందుకంటే మీకు ఆధారం ఉంది. అవును, ఇది చాలా వేగంగా ఉండకపోవచ్చు, కానీ వేగం "అండర్ ది హుడ్"పై ఆధారపడి ఉంటుంది, ఎందుకంటే కొన్ని అమలులు డిస్క్ సబ్‌సిస్టమ్ స్థాయిలో కాపీ మరియు కాపీ-ఆన్-రైట్ చేయగలవు.
NS: ఈ సంస్కరణకు మద్దతు ఇవ్వడం ప్రారంభించడానికి అన్ని ఇంజిన్‌లకు (అమెజాన్, గూగుల్...) కూడా ఇది అవసరం - దీనికి కూడా కొంత సమయం పడుతుంది.
DS: మేము వాటిని ఇంకా ఉపయోగించము. మేము మాది ఉపయోగిస్తాము.
కుబెర్నెటీస్ కోసం స్థానిక అభివృద్ధి
NS: మీరు అన్ని పాడ్‌లను ఒకే మెషీన్‌లో ఇన్‌స్టాల్ చేసి, ఇంత చిన్న పరీక్ష చేయవలసి వచ్చినప్పుడు మీకు అలాంటి కోరిక ఎదురైందా. కాన్సెప్ట్ యొక్క రుజువును త్వరగా పొందడానికి, అప్లికేషన్ కుబెర్నెట్స్‌లో మెషిన్‌ల సమూహాన్ని కేటాయించకుండానే నడుస్తుందని చూడండి. మినీక్యూబ్ ఉంది, సరియైనదా?
DS: ఈ కేసు - ఒక నోడ్‌లో అమలు చేయబడింది - ప్రత్యేకంగా స్థానిక అభివృద్ధికి సంబంధించినది అని నాకు అనిపిస్తోంది. లేదా అటువంటి నమూనా యొక్క కొన్ని వ్యక్తీకరణలు. తినండి , ఉంది , . మేము Kubernetes IN డాకర్‌ని ఉపయోగించే దిశగా కదులుతున్నాము. ఇప్పుడు మేము పరీక్షల కోసం దానితో పనిచేయడం ప్రారంభించాము.
NS: ఇది అన్ని పాడ్‌లను ఒకే డాకర్ ఇమేజ్‌లో చుట్టే ప్రయత్నం అని నేను భావించాను. కానీ ఇది పూర్తిగా భిన్నమైన విషయం అని తేలింది. ఏమైనప్పటికీ, ప్రత్యేక కంటైనర్లు, ప్రత్యేక పాడ్‌లు ఉన్నాయి - కేవలం డాకర్‌లో.
DS: అవును. మరియు చాలా ఫన్నీ అనుకరణ ఉంది, కానీ అర్థం ఇది... విస్తరణ కోసం మాకు ఒక యుటిలిటీ ఉంది - . మేము దీనిని షరతులతో కూడిన మోడ్‌గా చేయాలనుకుంటున్నాము werf up: "నాకు స్థానిక కుబెర్నెట్‌లను తీసుకురండి." ఆపై అక్కడ షరతు అమలు werf follow. అప్పుడు డెవలపర్ IDEని ఎడిట్ చేయగలరు మరియు మార్పులను చూసే మరియు చిత్రాలను పునర్నిర్మించే, వాటిని స్థానిక K8లకు మళ్లీ అమర్చే ప్రక్రియ సిస్టమ్‌లో ప్రారంభించబడుతుంది. ఈ విధంగా స్థానిక అభివృద్ధి సమస్యను పరిష్కరించేందుకు ప్రయత్నించాలన్నారు.
K8s రియాలిటీలో స్నాప్‌షాట్‌లు మరియు డేటాబేస్ క్లోనింగ్
NS: మనం కాపీ-ఆన్-రైట్‌కి తిరిగి వస్తే. మేఘాలకు స్నాప్‌షాట్‌లు కూడా ఉన్నాయని నేను గమనించాను. వారు భిన్నంగా పని చేస్తారు. ఉదాహరణకు, GCPలో: యునైటెడ్ స్టేట్స్ యొక్క తూర్పు తీరంలో మీకు బహుళ-టెరాబైట్ ఉదాహరణ ఉంది. మీరు క్రమానుగతంగా స్నాప్‌షాట్‌లను తీసుకుంటారు. మీరు స్నాప్‌షాట్ నుండి పశ్చిమ తీరంలో డిస్క్ యొక్క కాపీని ఎంచుకుంటారు - కొన్ని నిమిషాల్లో ప్రతిదీ సిద్ధంగా ఉంది, ఇది చాలా త్వరగా పని చేస్తుంది, కాష్ మాత్రమే మెమరీలో నింపాలి. కానీ ఈ క్లోన్‌లు (స్నాప్‌షాట్‌లు) కొత్త వాల్యూమ్‌ను 'ప్రొవిజన్' చేయడానికి ఉన్నాయి. మీరు చాలా సందర్భాలను సృష్టించాల్సిన అవసరం వచ్చినప్పుడు ఇది బాగుంది.
కానీ పరీక్షల కోసం, మీరు డాకర్‌లో మాట్లాడే స్నాప్‌షాట్‌లు లేదా నేను ZFS, btrfs మరియు LVMలో కూడా మాట్లాడినట్లు నాకు అనిపిస్తోంది... - అవి ఒక మెషీన్‌లో నిజంగా కొత్త డేటాను సృష్టించకుండా మిమ్మల్ని అనుమతిస్తాయి. క్లౌడ్‌లో, మీరు ఇప్పటికీ ప్రతిసారీ వారి కోసం చెల్లిస్తారు మరియు సెకన్లు కాదు, నిమిషాలు వేచి ఉండండి (మరియు సందర్భంలో , బహుశా ఒక గడియారం).
బదులుగా, మీరు ఈ డేటాను సెకను లేదా రెండు రోజుల్లో పొందవచ్చు, పరీక్షను అమలు చేసి, దాన్ని విసిరేయవచ్చు. ఈ స్నాప్‌షాట్‌లు వివిధ సమస్యలను పరిష్కరిస్తాయి. మొదటి సందర్భంలో - స్కేల్ అప్ మరియు కొత్త ప్రతిరూపాలను పొందడానికి, మరియు రెండవది - పరీక్షల కోసం.
DS: నేను అంగీకరించను. వాల్యూమ్ క్లోనింగ్ సరిగ్గా పని చేయడం క్లౌడ్ యొక్క పని. నేను వాటి అమలును చూడలేదు, కానీ హార్డ్‌వేర్‌లో దీన్ని ఎలా చేయాలో నాకు తెలుసు. మాకు సెఫ్ ఉంది, ఇది ఏదైనా భౌతిక వాల్యూమ్‌ను అనుమతిస్తుంది () చెప్పండి క్లోన్ మరియు పదుల మిల్లీసెకన్లలో అదే లక్షణాలతో రెండవ వాల్యూమ్‌ను పొందండి, 'అమీ, మొదలైనవి లోపల ఒక గమ్మత్తైన కాపీ-ఆన్-రైట్ ఉందని మీరు అర్థం చేసుకోవాలి. మేఘం ఎందుకు అలా చేయకూడదు? వారు దీన్ని ఒక మార్గం లేదా మరొక విధంగా చేయడానికి ప్రయత్నిస్తున్నారని నేను ఖచ్చితంగా అనుకుంటున్నాను.
NS: కానీ ఒక ఉదాహరణను లేవనెత్తడానికి, డాకర్‌ని అక్కడికి తీసుకురావడానికి, వారికి ఇంకా సెకన్లు, పదుల సెకన్లు పడుతుంది.
DS: మొత్తం ఉదాహరణను ఎందుకు పెంచాలి? మనకు 32 కోర్లతో ఒక ఉదాహరణ ఉంది, 16... మరియు అది దానికి సరిపోతుంది - ఉదాహరణకు, నాలుగు. మేము ఐదవదాన్ని ఆర్డర్ చేసినప్పుడు, ఉదాహరణ ఇప్పటికే పెంచబడుతుంది, ఆపై అది తొలగించబడుతుంది.
NS: అవును, ఆసక్తికరమైనది, కుబెర్నెటెస్ భిన్నమైన కథగా మారుతుంది. మా డేటాబేస్ K8sలో లేదు మరియు మాకు ఒక ఉదాహరణ ఉంది. కానీ మల్టీ-టెరాబైట్ డేటాబేస్ క్లోనింగ్ చేయడానికి రెండు సెకన్ల కంటే ఎక్కువ సమయం పట్టదు.
DS: ఇది చాలా గొప్ప విషయం. కానీ ఇది సాధారణ పరిష్కారం కాదని నా ప్రాథమిక అంశం. అవును, ఇది బాగుంది, కానీ ఇది పోస్ట్‌గ్రెస్‌కు మాత్రమే సరిపోతుంది మరియు ఒక నోడ్‌లో మాత్రమే.
NS: ఇది పోస్ట్‌గ్రెస్‌కు మాత్రమే సరిపోదు: ఈ ప్రణాళికలు, నేను వివరించినట్లు, దానిలో మాత్రమే పని చేస్తాయి. కానీ మేము ప్లాన్‌ల గురించి బాధపడకపోతే మరియు ఫంక్షనల్ టెస్టింగ్ కోసం మాకు మొత్తం డేటా అవసరమైతే, ఇది ఏదైనా DBMSకి అనుకూలంగా ఉంటుంది.
DS: చాలా సంవత్సరాల క్రితం మేము LVM స్నాప్‌షాట్‌లలో ఇలాంటిదే చేసాము. ఇది ఒక క్లాసిక్. ఈ విధానం చాలా చురుకుగా ఉపయోగించబడింది. స్టేట్‌ఫుల్ నోడ్స్ కేవలం నొప్పి మాత్రమే. మీరు వాటిని వదిలివేయకూడదు కాబట్టి, మీరు వాటిని ఎల్లప్పుడూ గుర్తుంచుకోవాలి ...
NS: మీకు ఇక్కడ హైబ్రిడ్ ఏదైనా అవకాశం కనిపిస్తోందా? స్టేట్‌ఫుల్ అనేది ఒక రకమైన పాడ్ అని అనుకుందాం, ఇది చాలా మందికి (చాలా మంది టెస్టర్‌లు) పని చేస్తుంది. మాకు ఒక వాల్యూమ్ ఉంది, కానీ ఫైల్ సిస్టమ్‌కు ధన్యవాదాలు, క్లోన్‌లు స్థానికంగా ఉంటాయి. పాడ్ పడిపోయినా, డిస్క్ మిగిలి ఉంటే, పాడ్ పెరుగుతుంది, అన్ని క్లోన్‌ల గురించిన సమాచారాన్ని లెక్కించి, అన్నింటినీ మళ్లీ ఎంచుకొని ఇలా చెప్పండి: "ఇక్కడ మీ క్లోన్‌లు ఈ పోర్ట్‌లలో నడుస్తున్నాయి, వాటితో పని చేయడం కొనసాగించండి."
DS: సాంకేతికంగా దీని అర్థం కుబెర్నెట్స్‌లో ఇది ఒక పాడ్, దానిలో మనం అనేక పోస్ట్‌గ్రెస్‌లను నడుపుతాము.
NS: అవును. అతనికి పరిమితి ఉంది: అతనితో ఒకే సమయంలో 10 మంది కంటే ఎక్కువ మంది పని చేయరని అనుకుందాం. మీకు 20 అవసరమైతే, మేము అలాంటి రెండవ పాడ్‌ను ప్రారంభిస్తాము. మేము దానిని పూర్తిగా క్లోన్ చేస్తాము, రెండవ పూర్తి వాల్యూమ్‌ను స్వీకరించిన తర్వాత, అది అదే 10 "సన్నని" క్లోన్‌లను కలిగి ఉంటుంది. మీకు ఈ అవకాశం కనిపించలేదా?
DS: మేము ఇక్కడ భద్రతా సమస్యలను జోడించాలి. ఈ రకమైన సంస్థ ఈ పాడ్ అధిక అధికారాలను (సామర్థ్యాలను) కలిగి ఉందని సూచిస్తుంది, ఎందుకంటే ఇది ఫైల్ సిస్టమ్‌లో ప్రామాణికం కాని ఆపరేషన్‌లను చేయగలదు... కానీ నేను పునరావృతం చేస్తున్నాను: మధ్యస్థ కాలంలో వారు కుబెర్నెట్స్‌లో నిల్వను పరిష్కరిస్తారని నేను నమ్ముతున్నాను. మేఘాలు వారు మొత్తం కథను వాల్యూమ్‌లతో పరిష్కరిస్తారు - ప్రతిదీ “కేవలం పని చేస్తుంది”. పునఃపరిమాణం, క్లోనింగ్ ఉంటుంది... ఒక వాల్యూమ్ ఉంది - మేము ఇలా అంటాము: “దాని ఆధారంగా కొత్తదాన్ని సృష్టించండి,” మరియు సెకనున్నర తర్వాత మనకు అవసరమైనది పొందుతాము.
NS: నేను చాలా టెరాబైట్‌ల కోసం ఒకటిన్నర సెకన్లలో నమ్మను. సెఫ్‌లో మీరు మీరే చేస్తారు, కానీ మీరు మేఘాల గురించి మాట్లాడతారు. క్లౌడ్‌కి వెళ్లి, EC2లో మల్టీ-టెరాబైట్ EBS వాల్యూమ్‌ను క్లోన్ చేయండి మరియు పనితీరు ఎలా ఉంటుందో చూడండి. దీనికి కొన్ని సెకన్ల సమయం పట్టదు. వారు ఎప్పుడు ఈ స్థాయికి చేరుకుంటారనే దానిపై నాకు చాలా ఆసక్తి ఉంది. మీరు చెప్పేది నాకు అర్థమైంది, కానీ నేను విభేదిస్తున్నాను.
DS: సరే, అయితే షార్ట్ టర్మ్ కాదు మీడియం టర్మ్ లో చెప్పాను. అనేక సంవత్సరాలు.
Zalando నుండి PostgreSQL కోసం ఆపరేటర్ గురించి
ఈ సమావేశం మధ్యలో, Zalando నుండి మాజీ డెవలపర్ అయిన Alexey Klyukin కూడా చేరారు మరియు PostgreSQL ఆపరేటర్ చరిత్ర గురించి మాట్లాడారు:
ఈ అంశం సాధారణంగా తాకడం చాలా బాగుంది: పోస్ట్‌గ్రెస్ మరియు కుబెర్నెట్స్ రెండూ. మేము 2017లో జలాండోలో దీన్ని చేయడం ప్రారంభించినప్పుడు, ఇది ప్రతి ఒక్కరూ చేయాలనుకున్న అంశం, కానీ ఎవరూ చేయలేదు. ప్రతి ఒక్కరూ ఇప్పటికే కుబెర్నెట్‌లను కలిగి ఉన్నారు, కానీ డేటాబేస్‌లతో ఏమి చేయాలని వారు అడిగినప్పుడు, వ్యక్తులు కూడా ఇష్టపడుతున్నారు , K8s గురించి బోధించిన వారు ఇలా అన్నారు:
“నిర్వహించబడిన సేవలకు వెళ్లి వాటిని ఉపయోగించండి, కుబెర్నెట్స్‌లో డేటాబేస్ను అమలు చేయవద్దు. లేకపోతే, మీ K8 లు నిర్ణయించుకుంటాయి, ఉదాహరణకు, అప్‌గ్రేడ్ చేయడానికి, అన్ని నోడ్‌లను ఆఫ్ చేయండి మరియు మీ డేటా చాలా దూరం ఎగురుతుంది.
మేము ఈ సలహాకు విరుద్ధంగా కుబెర్నెట్స్‌లో పోస్ట్‌గ్రెస్ డేటాబేస్ను ప్రారంభించే ఆపరేటర్‌ని తయారు చేయాలని నిర్ణయించుకున్నాము. మరియు మాకు మంచి కారణం ఉంది - . ఇది PostgreSQL కోసం ఆటోమేటిక్ ఫెయిల్‌ఓవర్, సరిగ్గా జరిగింది, అనగా. క్లస్టర్ గురించిన సమాచార నిల్వగా etcd, కాన్సుల్ లేదా ZooKeeperని ఉపయోగించడం. అడిగే ప్రతి ఒక్కరికీ అటువంటి రిపోజిటరీ ఇస్తుంది, ఉదాహరణకు, ప్రస్తుత నాయకుడు ఏమిటి, అదే సమాచారం - మేము ప్రతిదీ పంపిణీ చేసినప్పటికీ - స్ప్లిట్ మెదడు ఉండదు. ప్లస్ మేము కలిగి అతనికి.
సాధారణంగా, అంతర్గత హార్డ్‌వేర్ డేటా సెంటర్ నుండి క్లౌడ్‌కి మారిన తర్వాత కంపెనీ ఆటో ఫెయిల్‌ఓవర్ అవసరం కనిపించింది. క్లౌడ్ యాజమాన్య PaaS (ప్లాట్‌ఫారమ్-యాజ్-ఎ-సర్వీస్) పరిష్కారంపై ఆధారపడింది. ఇది ఓపెన్ సోర్స్, కానీ దీన్ని అమలు చేయడానికి మరియు అమలు చేయడానికి చాలా పని పట్టింది. అని పిలిచేవారు .
ప్రారంభంలో, కుబెర్నెట్స్ లేరు. మరింత ఖచ్చితంగా, మా స్వంత పరిష్కారం అమలు చేయబడినప్పుడు, K8 లు ఇప్పటికే ఉనికిలో ఉన్నాయి, కానీ ఇది చాలా ముడిగా ఉంది, అది ఉత్పత్తికి తగినది కాదు. ఇది నా అభిప్రాయం ప్రకారం, 2015 లేదా 2016. 2017 నాటికి, కుబెర్నెట్స్ ఎక్కువ లేదా తక్కువ పరిణతి చెందారు-అక్కడికి వలస వెళ్లవలసిన అవసరం ఉంది.
మరియు మాకు ఇప్పటికే డాకర్ కంటైనర్ ఉంది. డాకర్‌ని ఉపయోగించే PaaS ఉంది. K8లను ఎందుకు ప్రయత్నించకూడదు? మీ స్వంత ఆపరేటర్‌ను ఎందుకు వ్రాయకూడదు? అవిటో నుండి మా వద్దకు వచ్చిన మురాత్ కబిలోవ్, దీనిని తన స్వంత చొరవతో ప్రాజెక్ట్‌గా ప్రారంభించాడు - “ఆడడానికి” - మరియు ప్రాజెక్ట్ “టేకాఫ్.”
కానీ సాధారణంగా, నేను AWS గురించి మాట్లాడాలనుకుంటున్నాను. చారిత్రక AWS సంబంధిత కోడ్ ఎందుకు వచ్చింది...
మీరు Kubernetes లో ఏదైనా అమలు చేసినప్పుడు, K8s అటువంటి పని పురోగతిలో ఉందని మీరు అర్థం చేసుకోవాలి. ఇది నిరంతరం అభివృద్ధి చెందుతోంది, మెరుగుపడుతుంది మరియు ఎప్పటికప్పుడు విచ్ఛిన్నమవుతుంది. మీరు కుబెర్నెటెస్‌లోని అన్ని మార్పులను నిశితంగా గమనించాలి, ఏదైనా జరిగితే దానిలోకి ప్రవేశించడానికి మీరు సిద్ధంగా ఉండాలి మరియు అది ఎలా పనిచేస్తుందో వివరంగా తెలుసుకోండి - బహుశా మీరు కోరుకున్న దానికంటే ఎక్కువ. ఇది సూత్రప్రాయంగా, మీరు మీ డేటాబేస్‌లను అమలు చేసే ఏ ప్లాట్‌ఫారమ్‌కైనా వర్తిస్తుంది...
కాబట్టి, మేము ప్రకటన చేసినప్పుడు, మేము పోస్ట్‌గ్రెస్‌ను బాహ్య వాల్యూమ్‌లో రన్ చేసాము (ఈ సందర్భంలో EBS, మేము AWSలో పని చేస్తున్నందున). డేటాబేస్ పెరిగింది, ఏదో ఒక సమయంలో దాని పరిమాణాన్ని మార్చడం అవసరం: ఉదాహరణకు, EBS యొక్క ప్రారంభ పరిమాణం 100 TB, డేటాబేస్ దానికి పెరిగింది, ఇప్పుడు మేము EBS 200 TB చేయాలనుకుంటున్నాము. ఎలా? మీరు కొత్త సందర్భంలో డంప్/పునరుద్ధరణ చేయగలరని అనుకుందాం, అయితే దీనికి చాలా సమయం పడుతుంది మరియు పనికిరాని సమయం ఉంటుంది.
అందువల్ల, నేను EBS విభజనను విస్తరించి, ఆపై కొత్త స్థలాన్ని ఉపయోగించమని ఫైల్ సిస్టమ్‌కి చెప్పే పరిమాణాన్ని మార్చాలనుకుంటున్నాను. మరియు మేము దీన్ని చేసాము, కానీ ఆ సమయంలో కుబెర్నెట్స్ పునఃపరిమాణం ఆపరేషన్ కోసం ఏ APIని కలిగి లేదు. మేము AWSలో పనిచేసినందున, మేము దాని API కోసం కోడ్‌ని వ్రాసాము.
ఇతర ప్లాట్‌ఫారమ్‌ల కోసం అదే పని చేయకుండా మిమ్మల్ని ఎవరూ ఆపడం లేదు. ఇది AWSలో మాత్రమే అమలు చేయబడుతుందని ప్రకటనలో ఎటువంటి సూచన లేదు మరియు ఇది మిగతా వాటిపై పని చేయదు. సాధారణంగా, ఇది ఓపెన్ సోర్స్ ప్రాజెక్ట్: ఎవరైనా కొత్త API వినియోగాన్ని వేగవంతం చేయాలనుకుంటే, మీకు స్వాగతం. తినండి , అభ్యర్థనలను లాగండి - Zalando బృందం వాటికి చాలా త్వరగా ప్రతిస్పందించడానికి మరియు ఆపరేటర్‌ను ప్రోత్సహించడానికి ప్రయత్నిస్తుంది. నాకు తెలిసినంత వరకు, ప్రాజెక్ట్ Google సమ్మర్ ఆఫ్ కోడ్ మరియు కొన్ని ఇతర సారూప్య కార్యక్రమాలలో. జలాండో దానిపై చాలా చురుకుగా పనిచేస్తున్నాడు.
PS బోనస్!
మీకు PostgreSQL మరియు Kubernetes అంశంపై ఆసక్తి ఉంటే, దయచేసి తదుపరి పోస్ట్‌గ్రెస్ మంగళవారం గత వారం జరిగిందని, నేను నికోలాయ్‌తో మాట్లాడానని కూడా దయచేసి గమనించండి. జలాండో నుండి అలెగ్జాండర్ కుకుష్కిన్. దాని నుండి వీడియో అందుబాటులో ఉంది .
PPS
మా బ్లాగులో కూడా చదవండి:
- «";
- «";
- «";
- «".
మూలం: www.habr.com