Názory k článku Jak se staví CDN: úvod a použité komponenty
-
Děkuji za hezký článek a těším se na pokračování. Před lety jsem se kolem tvorby jedné CDN pohyboval, tak jsem zvědavý na vaše řešení.
Jenom drobnost, nebylo by lepši kontrolovat syntaktickou správnost konfigu (což je vlastně všechno, co configtest dělá) už během CI fáze?
Alespoň já mám raději, když se případný červený nápis objeví 3-4 minuty po commitu než až během přehrávání playbooku :) -
Ano, s tím samozřejmě souhlasím :) Configtest provádějte ideálně co nejrychleji a po jakékoliv změně v konfiguraci. Čím dříve ve workflow se o problému dozvíte, tím efektivněji ho vyřešíte.
Mým cílem bylo upozornit na to, že v některých distribucích init skripty implicitně configtest neprovádí před všemi akcemi. Může se tedy stát, že zavoláte např. restart - nejdřív se služba stopne a pak vám před startem configtest zahlásí chybu, co už je pozdě, protože služba neběží a nenastartuje. Pokud má daná technologie i reload, tak ten je výrazně bezpečnější volba, ale některé změny konfigurace můžou restart vyžadovat (typicky binding na IP adresy a porty).
-
Co bylo zrejme take rozhodujici proti hotovemu reseni, 30-100kkc skutecne neni moc, byla zrejme i nizka cena prace v CR kterou je nutno do projektu take kalkulovat.
Porad lze narazit na headhuntera ktery za praci na takovem projektu vic jak cca 60kkc nenabidne. I kdyz realne je to nekde 100-150kkc na fultime.
V CR/SK bych se rozhodl stejne. Byt ty racionalni duvody proc to tak je jsou mi samozrejme "proti srsti".11. 11. 2020, 10:28 editováno autorem komentáře
-
100k je docela hodně. Za rok to je 1.2M a to už je částka, se kterou se dá postavit ledasco. Vlastní řešení má smysl v případě, že člověk chce postupně škálovat nahoru. Pokud by, zjednodušeně řečeno, mělo 200 GB obsahu stát 200k měsíčně a vím, že to budu potřebovat, je nesmysl si to nepostavit, když vím jak. Za měsíc za dva ten projekt může být hotový a náklady na něj neprekročí roční výdaje za hotové řešení, i když ti vývojáři dostanou těch 150k. Výdaje za hardware budou zanedbatelné i v případě, že se pro servery použijí nějaké cloudové služby.
-
Co se týče zmíněného RFC7871/edns tak pozor na Cloudflare - neumí to (zatím). Pro rozhodování odkud dotazující klient je, používá ip adresu posledně ptajícího-se resolveru. Tedy pokud má provider z indie nastavený resolver nějaký 8.8.8.8 může se klient jevit jako kdyby přišel např z Anglie. Záleží, kde zrovna skončí v rámci 8.8.8.8 jeho požadavek.
-
Jen doplnim, ze Cloudflare 1.1.1.1 (rekurzor) EDNS Client Subnet neposila schvalne a tvrdi, ze je to kvuli soukromi a bezpeci jeho uzivatelu.
Cloudflare Traffic (autoritativni DNS/GeoDNS balancer) dokonce nebere v potaz ani IP adresu klientova resolveru, ale jen a pouze to, do jakeho Cloudflare datacentra provoz dorazil.
Pokud je tedy treba provoz na Cloudflare z Afriky preroutovan do Evropy, rozhodne GeoDNS Cloudflaru podle pravidla "vydej mu zaznamy pro Evropu".BTW asi preklep, misto 8.8.8.8 jsi mozna chtel napsat 1.1.1.1? :)
-
Pro zjistovani latenci a traceroutu od uzivatelu se vyborne hodi i projekt RIPE Atlas. Vyuziva sond, ktere jsou casto v sitich koncovych ISP, nebo primo v domacnostech uzivatelu. Umoznuje testovat ping, traceroute a kontrolovat preklady DNS z ruznych mist na svete.
Daji se tim perfektne odhalovat treba zaludnosti v tranzitnim routingu (jako treba routing z jedne africke zeme do jine pres Francii/Spanelsko/Britanii).
-
Radku, děkuji za super tip na RIPE Atlas. Už jsem jim odeslal žádost o jejich HW probe. Budeme moct probe poskytnout pro 4 AS-ka v ČR.
Zároveň vidím, že jejich SW probes https://atlas.ripe.net/docs/software-probe/ můžeme provozovat i na našich CDN serverech (Debiany), takže určitě se mezi těmi 20 dalšími AS objeví i nějaké, které ještě pokryté nemají.
ČLÁNKY DO MAILU