Cluster - Spotter project backup #5

New Issue

2022-04-03T11:45:31+02:00

Podhorecky commented

2022-04-03 11:45:31 +02:00

(Migrated from git.spotter.cz)

účelem tohoto stacku je vytvořit aktivní zálohu projektových dat na lokálním serveru

takže především:

GitLab

NextCloud

Odoo

uvidím co dál.Něco k zamyšlení

účelem tohoto stacku je vytvořit aktivní zálohu projektových dat na lokálním serveru takže především: **GitLab** **NextCloud** **Odoo** uvidím co dál.Něco [k zamyšlení](https://www-resilience-org.translate.goog/stories/2022-04-01/the-toxic-cloud-called-internet/?_x_tr_sl=en&_x_tr_tl=cs&_x_tr_hl=cs&_x_tr_pto=wapp)

Podhorecky commented

2022-04-03 11:46:19 +02:00

(Migrated from git.spotter.cz)

changed the description

Podhorecky commented

2022-04-03 11:51:47 +02:00

(Migrated from git.spotter.cz)

changed the description

Disassembler commented

2022-04-03 13:02:41 +02:00

(Migrated from git.spotter.cz)

Povedzte Kefalín, čo vy si predstavujete pod takým slovom "aktivní záloha"?

V IT světě se obvykle aktivní zálohou myslí HA (high availability) scénář ve kterém existuje loadbalancovaný cluster, kde se uzly určené jako záložní synchronizují s aktivními, ale nezpracovávají žádné požadavky, a load balancer na ně přepne provoz jakmile ty primární přestanou být dostupné. (OK, ve skutečnosti ani tohle není úplně aktivní, protože ten scénář se jmenuje Active-Passive, ale nešť.) V takových případech se jednotlivé HA řeší na úrovni služeb, nikoliv na úrovni aplikací, protože každá služba si s replikami vyměňuje informace po svém (transakční logy u databázových služeb a messagingu, in-memory replikace u aplikačních serverů, soubory, bloky a metadata u úložišť atd.)

Konkrétně třeba u GitLabu je replikace placená featura (Premium, $19 per user/month) a její nasazení je doporučováno ve scénářích od tří tisíc aktivních uživatelů, což vcelku není divu, vzhledem k tomu, že je potřeba replikovat stavy asi třiceti služeb.

Pokud tím myslíte ale jen to, že se třeba každých šest hodin udělají dumpy databáze a spolu s konfiguracemi a daty v úložišti někam odstěhují, odkud je možno je v případě potřeby obnovit (ne nutně pouze do původního umístění), pak je to prostě "záloha" a ta by měla být úplně běžnou součástí správy jakéhokoliv serveru.

Povedzte Kefalín, čo vy si predstavujete pod takým slovom "aktivní záloha"? V IT světě se obvykle aktivní zálohou myslí HA (high availability) scénář ve kterém existuje loadbalancovaný cluster, kde se uzly určené jako záložní synchronizují s aktivními, ale nezpracovávají žádné požadavky, a load balancer na ně přepne provoz jakmile ty primární přestanou být dostupné. (OK, ve skutečnosti ani tohle není úplně _aktivní_, protože ten scénář se jmenuje _Active-Passive_, ale nešť.) V takových případech se jednotlivé HA řeší na úrovni služeb, nikoliv na úrovni aplikací, protože každá služba si s replikami vyměňuje informace po svém (transakční logy u databázových služeb a messagingu, in-memory replikace u aplikačních serverů, soubory, bloky a metadata u úložišť atd.) Konkrétně třeba u GitLabu je replikace placená featura (Premium, $19 per user/month) a její nasazení je doporučováno ve scénářích od [tří tisíc aktivních uživatelů](https://docs.gitlab.com/ee/administration/reference_architectures/3k_users.html), což vcelku není divu, vzhledem k tomu, že je potřeba replikovat stavy asi třiceti služeb. Pokud tím myslíte ale jen to, že se třeba každých šest hodin udělají dumpy databáze a spolu s konfiguracemi a daty v úložišti někam odstěhují, odkud je možno je v případě potřeby obnovit (ne nutně pouze do původního umístění), pak je to prostě "záloha" a ta by měla být úplně běžnou součástí správy jakéhokoliv serveru.

Podhorecky commented

2022-04-03 13:28:38 +02:00

(Migrated from git.spotter.cz)

Ok... otázka na místě. Já nevim jestli používám zrovna přesný termín, který už je používaný jinak, proto to vysvětlím.

Nepotřebuji high-availability. Nepotřebuju ani dumpy každých 6 hodin. Můžu potřebovat dump tak, abych ho měl až to bude potřeba.
Je mi jasné, že furt je miliarda způsobů jak zálohovat data z jednoho cloudu do jiného cloudu. Stojí to méně, než jeden kebab v Západním Turecku.
Potřebuji workflow, kdy budu moci v krátké době udělat rozhodnutí, že SW a data z hostingu odmigruji, protože bude hosting z mého úhlu pohledu (nikoliv obecně) nedostupný, nebo rizikový.

V té chvíli budou pro mne (z mého úhlu pohledu) nedostupné neodkladné operace a služby něčeho, nebo někoho jiného.

Pak pro mne bude přínosné, že moje migrační rozhodnutí bude:

refreshnout si lokálně ulažená data tak, aby byla aktuální
ověřit si že SW je připraven buď k fungování jak je, nebo k budoucímu nasazení jinde
ukončení hostingu s poctem že jsem nic nezanedbal a že můžu s nějakým menším komfortem pokračovat dál

Když ta potřeba nebude, tak tento scénář nepoužiji.

Nepřijatelný scénář je:

Aha.. asi je/bude problém že... X.. Y.. Z..
Aha.. von mi nikdo nezvedá telefon a neodpovídá mi na mail.
Ok, srát na to, šak to byly jen nějaká data na hostingu.

V tuto chvíli to není neodkladné, ale považuji to za nějaký zvážený postup, který bych později chtěl provést.

Můžete se tomu smát jak chcete, ale mám nabídku od kamaráda, že v případě potřeby mohu změnit lokál do HongKongu, nebo jiného George Townu. Je to shodou okolností na stejné Zeměkouli, ale nikdo nevíme, jak za pár let přijde někomu zajímavé omezit dostupnost internetu do takové shnilé díry, jako je Evropa. S mým tempem bych tyhle věci nechtěl řešit až v okamžiku, až se stanou a já bych začal shánět nějakého p. Jebavého z Kalifornie. Vím přesně jak by to dopadlo, když už vím, jak to dopadlo před měsícem, kdy jsem mu nabízel 150tis. a více peněz.

Založil jsem tu projekt FreedomBoxu abych si to trochu urovnal a jsem rád, že mi na to reagujete, že to vidíte svým pohledem. Skeptické pohledy jsou někdy víc užitečné, než optimistické. Stále hledám tu "kvalitní odpověď na nepříjemné otázky" ... já ji nemám a nikdo mi ji jen tak sám od sebe nedá.

Ok... otázka na místě. Já nevim jestli používám zrovna přesný termín, který už je používaný jinak, proto to vysvětlím. **Nepotřebuji high-availability**. Nepotřebuju ani dumpy každých 6 hodin. Můžu potřebovat dump tak, abych ho měl až to bude potřeba. Je mi jasné, že furt je miliarda způsobů jak zálohovat data z jednoho cloudu do jiného cloudu. Stojí to méně, než jeden kebab v Západním Turecku. Potřebuji workflow, kdy budu moci v krátké době udělat rozhodnutí, že SW a data z hostingu odmigruji, protože bude hosting z mého úhlu pohledu (nikoliv obecně) nedostupný, nebo rizikový. V té chvíli budou pro mne (z mého úhlu pohledu) nedostupné neodkladné operace a služby něčeho, nebo někoho jiného. Pak pro mne bude přínosné, že moje migrační rozhodnutí bude: 1. refreshnout si lokálně ulažená data tak, aby byla aktuální 2. ověřit si že SW je připraven buď k fungování jak je, nebo k budoucímu nasazení jinde 3. ukončení hostingu s poctem že jsem nic nezanedbal a že můžu s nějakým menším komfortem pokračovat dál Když ta potřeba nebude, tak tento scénář nepoužiji. Nepřijatelný scénář je: 1. Aha.. asi je/bude problém že... X.. Y.. Z.. 2. Aha.. von mi nikdo nezvedá telefon a neodpovídá mi na mail. 3. Ok, srát na to, šak to byly jen nějaká data na hostingu. V tuto chvíli to není neodkladné, ale považuji to za nějaký zvážený postup, který bych později chtěl provést. Můžete se tomu smát jak chcete, ale mám nabídku od kamaráda, že v případě potřeby mohu změnit lokál do HongKongu, nebo jiného George Townu. Je to shodou okolností na stejné Zeměkouli, ale nikdo nevíme, jak za pár let přijde někomu zajímavé omezit dostupnost internetu do takové shnilé díry, jako je Evropa. S mým tempem bych tyhle věci nechtěl řešit až v okamžiku, až se stanou a já bych začal shánět nějakého p. Jebavého z Kalifornie. Vím přesně jak by to dopadlo, když už vím, jak to dopadlo před měsícem, kdy jsem mu nabízel 150tis. a více peněz. Založil jsem tu projekt FreedomBoxu abych si to trochu urovnal a jsem rád, že mi na to reagujete, že to vidíte svým pohledem. Skeptické pohledy jsou někdy víc užitečné, než optimistické. Stále hledám tu "kvalitní odpověď na nepříjemné otázky" ... já ji nemám a nikdo mi ji jen tak sám od sebe nedá.

Podhorecky commented

2022-04-03 15:27:48 +02:00

(Migrated from git.spotter.cz)

Russia is risking the creation of a “splinternet”—and it could be irreversible

[Russia is risking the creation of a “splinternet”—and it could be irreversible](https://www.technologyreview.com/2022/03/17/1047352/russia-splinternet-risk/)

Sign in to join this conversation.