Názory k článku Na návštěvě stavby olejového datacentra: bunkr pro servery v Hluboké

Ano, vše se snažíme dělat společně. Ono jde i o záruky serverů.
HPE nám například poslalo upravené zdroje z USA, které jsou softwarově upravené pro potopení.

Servery mají 4 zdroje a když jsou potopené v oleji, tak k provozu stačí 1. Rezervy tam jsou. Navíc za celou dobu 7 let jsme měnili snad 1 zdroj a to máme přes tisíc fyzických serverů.
Jinak máme servisní smlouvy. Nebojte. A vždy náhradní díly. Nebojte. A vždy náhradní kapacity.

Psal jste tohle někdy k nám? Adresáře a jejich názvy snad nikdo nikdy nezpochybnil.

Pokud jde o další připomínky, tak jsme dali na web náš webpagetest a ten často ukáže, že generování stránek čeká 5 sekund na facebook nebo 2 sekundy na google fonty a tak by šlo pokračovat. Máme 2 CMS specialisty, kteří se klientům věnují a to nad rámec podpory. A tak by šlo pokračovat. Neříkám, že se nemůže vyskytnout chyba u nás. Řešili jsme útoky na CMS, které byly plošné. Před rokem jsme nasadili IDS/IPS a máme klid. 40% provozu se odfiltruje ještě před servery a je klid.

Inovace máme a pořád děláme další. Zkuste třeba náš nový hosting, který nyní testujeme na HPE Moonshot. Nic rychlejší asi k dispozici není. Navíc u této varianty budeme mít nejen sdílenou verzi, ale i vyhrazenou. Tak si koupíte výkon, který bude jen a pouze Váš.

Helpdesk je k dispozici 24/7 a snaží se. Ano, máme několik stovek aktualizovaných a profesionálně udělaných návodů a na ty odkazujeme. Jsou věci, které děláme a jsou věci, které neděláme. Od počátku tvrdíme, že míříme na 98% klientů a individuální nastavení neděláme. Ano, tak to je. Tak bohužel nemůžeme vyhovět každému a není to neochota, ale to, že máme vše jednotné a plně automatizované a neexistují ústupky.
My skutečně nikde neděláme ústupky. A nikdo z techniků a už vůbec ne na podpoře.. nemá šanci to obejít. I kdyby sebevíc chtěli, tak to nejde. Máme tak náš systém nastavený. Díky tomu máme jednotné a funkční prostředí, kde aktuálně hostujeme přes 130.000 webhostingů a přes 6.500 virtuálních serverů, nějaké dedikované... a to celkově na více než 1.000 fyzických serverech.

Ze všech podnětů se poučujeme a posouváme dále. Nyní třeba ten HPE Moonshot se silnými a rychlými CPU. Tam poznáte skokově rozdíl. Budeme mít garantovaný výkon, který si zaplatíte. I to je pokrok a reakce na podněty. Bude tam možné nastavit zcela individuálně cokoliv v PHP a tak by šlo pokračovat. To bude služba, kterou hledáte. Tam naopak budeme umět nastavit cokoliv.

Jsem přesvědčen, že potom názor změníte.

Limit máme schválně, aby nám tam zákazníci nevkládali miliony nesmyslů, ale vždy to dokážeme navýšit a vždy to navyšujeme.

DNSSEC u COM domén nezávisí na nás, ale na našem registrátorovi a plné automatizaci tam. Dříve než tam to možná uděláme sami, protože chceme požádat o akreditaci.

Napsal jsem to, jak to je. Limit 100 záznamů vždy dokážeme navýšit a nikdy jsme asi nikoho neodmítli, ale máme v tom prostě přehled. Určitě to využívá zlomek klientů a není to tedy nic omezujícího. Nezapomínejte, že u nás to jde vkládat přes WAPI, tedy naše API a tam potom můžete vložit třeba tisíce záznamů jedním kliknutím.

DNSSEC - je to tak, jak jsem napsal. Nuda to je, ale (i) proto připravujeme vlastní akreditaci.

Nechápu v čem máte problém? Limit navyšujeme. Nikdy jsme navýšení nikomu neodmítli a tak nechápu.
Službu DNS poskytujeme ke všem doménám zdarma. A to domény prodáváme za nákupní ceny, bez jakékoliv marže. Máme tam nějaká pravidla a tak je dodržujeme. Není to nic proti zákazníkům, ale ochrana před přetížením apod.
Pokud se na nás obrátíte, tak Vám limit navýšíme. Stejně jsme to udělali v jiných případech, tak i v tomto. A to zdarma.

Přes API máme také omezení na 100 záznamů. Tam jsou duševní pochody stejné. Jsou to naše podmínky a musíme se nějak bránit. Pokud chceme, aby DNS servery fungovaly v pořádku a proběhla vždy aktualizace v pořádku, tak to není jen tak. Pokud jste měl povoleno přes 100 záznamů, tak by to nemělo blokovat. Řešil jste to s někým u nás?

DNSSEC budeme chtít udělat, ale když to nemá dodavatel, tak nemůžeme nic. Když si neuděláme vlastní akreditaci, tak jsme v koncích a to není snadná záležitost. Trvá to.
DNSSEC v množství domén, které spravujeme a vedeme v DNS, také není sranda. Na jaře jsme se na tom spálili a bylo to nepříjemné i pro klienty.

Olej je cesta dopředu a věřte, že je to z hlediska budoucnosti a nákladů a rozvoje firmy mnohem důležitější, než zda budeme mít DNSSEC u generických domén dnes nebo za půl roku.
Snad jsem to vysvětlil. Děkuji za pochopení.

Ne, já jsem netvrdil, že přes API není limit, ale že přes API snadno dáte záznamů velké množství. Výchozí limit je dostačující pro 99,9% všech klientů. A tomu zbytku to navýšíme. V čem je tedy problém?

Pokud Vám u nás chybí DNSSEC u generických domén, tak prostě nemohu nyní sloužit. Důvody jsem vysvětlil. U domén, které prodáváme za nákupní ceny umíme nastavit prakticky vše co lze. To je důležité pro 250.000 domén, které naše DNS využívají. Jen u generických nemáme z objektivních důvodů DNSSEC. Těch generických domén je asi 25.000 a aktuálně by to využilo několik jednotlivých zákazníků. Věřte, že to potom pro nás nemá prioritu takovou, jako třeba "máchání" serverů v oleji, které nám ročně ušetří miliony za energie a má to vliv na všechny zákazníky. Za ušetřené peníze můžeme být výhodnější, než konkurence a můžeme to zase investovat do rozvoje firmy. To je podstatné a to má prioritu. Věci řešíme podle priorit.

Objektivní důvody jsem napsal. Pokud Vám to nevyhovuje, tak buď musíte počkat až to budeme mít nebo musíte mít doménu bohužel jinde (minimálně do doby, než to mít budeme). Nejsme kouzelníci a nemůžeme mít všechno hned a ani to nikde neslibujeme. Děkuji za pochopení.

Řekl bych, že váš předpoklad, že pan Grill nikdy nebyl v datacentru Wedosu v Hluboké nebo v Budějovicích na náměstí, je dost odvážný. Nebo se jen neorientujete v tom, kdo co v komentářích napsal?

Model záplav Hluboké 7 metrů nad tisíciletou vodu asi nikdo nemá, takže já jsem to vyjádření pana Grilla chápal hlavně jako vyjádření pravděpodobnosti než jako přesný údaj, jak vysoko by byla hladina v Českých Budějovicích. Navíc odhadovat zaplavené území podle mapy je asi tak stejně přesné, jako tvářit se, že sedm metrů nad tisíciletou vodu je všude stejná povodeň. Ona totiž ta voda v zúženém profilu najednou nepoteče do kopce, ale bude se rozlévat před tím zúženým místem a hladina v tom zúženém místě bude o něco níž, než v tom rozlivu před ním – jinak by totiž ta voda oním zúženým místem neodtékala, že.

ono se to chce pokusit pochopit význam toho shluku písmen, kterému se říká slova a věty.
Jo jo, to doporučuju. Nevzdávejte to, jednou se vám to podaří.

Ten, co tam zjevně nikdy nebyl bude spíš ten nativní tapetovač Jirsák
Na to, abych upozornil, že „o 7 metrů výše“ se vztahuje k tisícileté vodě, nepotřebuji být na Hluboké. K tomu úplně stačí, když pochopím význam textu. Taky to někdy zkuste.

co je to ta H2O a jak se obvykle chová
Do kopce obvykle neteče. Nastudovat, jak se voda chová v úzkém místě, můžete například na nějakém jezu, kde se voda nepouští přes korunu, ale šlajsnou nebo náhonem. Můžete si tam všimnout takového zajímavého jevu, že hladina nad jezem je výš než hladina pod ním, a tím úzkým místem, třeba náhonem, se ty hladiny vyrovnávají, takže v tom náhonu teče voda se shora dolů – na začátku náhonu je hladina v úrovni hladiny nad jezem, na konci v úrovni hladiny pod jezem.

Používáme úplně obyčejné grundfosy, ale testujeme i neznačkové řešení. Vše funguje. Náš olej má nízkou viskozitu a tak s tím není problém.

Kancelářská budova je v přízemí jako společenská místnost a i tato místnost je nad hranicí tisícileté vody. Kanceláře jsou o cca 4,5 metru výše. Přístup tam je i z druhé strany budovy, tj. z kopce, který je o 60 metrů vyšší. Tam není problém se dostat kdykoliv.
Trafostanice je za budovou, mimo velkou vodu, ale kdyby technicky selhala, tak nepodceňujeme nic. Běh bez energií - 3 linie generátorů, celkem složeno z 5 kusů strojů. Každá linie na 100% výkonu celého datacentra a s nádrží na 12 hodin provozu 100%. Počítáme 100% osazení, které nikdy nebude, protože nikdy nemůžeme vše osadit na 100% a nemít rezervu... K tomu další naftové hospodářství přímo na místě, které bude schopno pokrýt automaticky několik dalších dní provozu a k tomu vždy možnost doplňování i ze strany kopce. Máme tam pozemek.
My jsme skutečně nad takovými alternativami přemýšleli a uvažovali jsme i nad problémy co kdyby.

Ne, psalo se o 254 serverech, které se vejdou do jednoho IP rozsahu. Takže třeba
.0 – server1
.1 – server2
…
.253 – server254
.254 – rezerva
.255 – broadcast

Takže se vejdou.

Máte naprostou pravdu. Některým lidem se tady nedá nic vysvětlit. Někdy to nechtějí pochopit. Někdy platí úměra - čím více anonymní, tím více přesvědčený :-)

Jak jsem uvedl - my stejně vše nenasadíme, protože si vždy něco necháváme jako "hardwarovou zálohu". Nevyužité IP se využijí, protože pár klientů bude chtít o IP navíc.

Ne, nenapsal jsem žádnou blbost. V segmentu /24 je právě 256 adres použitelných klienty. IP protokol používá pro směrování pouze IP adresy, nezná žádnou adresu sítě nebo masku sítě. Rozdělení na sítě je pouze administrativní záležitost a věc zvyku a dohody. Např. to, že se IP adresa s lokální adresou obvykle používá jako broadcast. Ano, je dost programů, které s tímhle počítají, takže pokud byste takovou adresu použil jako IP adresu zařízení, budou některé programy protestovat a některé možná nebudou vůbec fungovat. Ale to je nedokonalost těch programů. Pokud s tou adresou bude komunikovat někdo z venku sítě, nebude s tím mít žádný problém, protože dotyčný vůbec netuší, jestli máte ve své síti /24 nebo /22 nebo třeba /16. To, že se lokální adresa se samými nulami označuje jako adresa sítě a obvykle se při adresování vynechává, je už čistě administrativní záležitost, nevím o tom, že by tu adresu nějaký program řešil nějak speciálně (což neznamená, že takový neexistuje). Router ani brána ani nic takového také nemusí být součást daného adresního prostoru, i když jsou zařízení propojená s dalšími sítěmi. Zařízení mohou být např. dostupná i pod jinými IP adresami a spojení do jiných sítí mohou mít přes ně. A nebo prostě může mít brána nebo router IP adresu z jiného rozsahu. Např. v datacentru můžete mít přidělený „rozsah“ /32, a není s tím žádný problém.

To, že víte, jak se něco obvykle dělá, ještě neznamená, že rozumíte tomu, jak to celé doopravdy funguje. Takže pokud někdo napíše něco, co není v souladu s vašimi omezenými znalostmi, nutně to neznamená, že píše blbosti – možná prostě jenom ví o dané věci víc, než vy.

Diskuze tady byla o tom, jestli lze na /24 využít adresy {N, SN, 0} a {N, SN, -1} jako zdrojové adresy pro odchozí provoz.
Nikoli, diskuse byla o tom, jestli lze do rozsahu /24 dostat 254 serverů. Přičemž vynecháme-li řešení, že to ve skutečnosti bude součást /23 sítě nebo větší, pořád jsou k dispozici minimálně tři řešení, z nichž dvě neodporují žádnému RFC.

jako zdrojové adresy pro odchozí provoz. A k tomu tvrdím, že při dodržení RFC to nelze.
Jenže rozdělení IP adresy na adresu sítě a lokální část adresy platí jenom v té vaší síti. Jakmile paket opustí hraniční router směrem ven, je zdrojová IP adresa prostě jen IP adresou, žádná adresa sítě tam není. Takže o tom vašem porušení RFC se nikdo nedozví a nikomu to nevadí.

A navíc, jak už bylo mnohokrát řečeno, když z prostoru /24, tedy 256 adres, odeberete ty dvě krajní „rezervované“, pořád vám zbyde 254 adres k použití, což k pokrytí 254 serverů stačí.

O žádné globální změně nebyla řeč. Dokonce ani nebyla řeč o tom, že by ten rozsah /24 musel tvořit samostatnou síť.

Sítě třídy A až E dle RFC1122 se už dnes nepoužívají, ukázalo se, že je potřeba jemnější dělení (někdy se ze setrvačnosti síť o příslušné velikosti označuje daným písmenem, ale to neznamená, že není možné mít i jinak velké sítě). Podstatné ale je, že tohle jsou doporučené postupy pro organizaci lokální sítě, vtip internetu ale spočívá v tom, že dokud budete umět přijímat a odesílat správně strukturované IP pakety, můžete s okolním internetem bez problémů komunikovat, bez ohledu na to, jak vypadá vaše interní struktura sítě. Takže když vám řeknu, že máte navázat spojení s IP adresou 216.58.209.0, tak vám nic nebrání takové spojení navázat, protože z venku nevíte nic o tom, jestli v cíli je cílová síť 216.58.209.0/24 nebo třeba 216.58.208.0/22. Nicméně tohle jsem uváděl jako perličku, že když máte síť pod kontrolou a víte, co děláte, dají se použít i ty rezervované IP adresy.

Podstatné je ale to, že i když odečtete tyto rezervované IP adresy, je k dispozici v /24 síti 254 IP adres k přidělení, což pro 254 serverů stačí.

Ad 1 – Nepsal jsem nic o tom, zda někdo něco povoluje nebo nepovoluje. Psal jsme, co je technicky proveditelné, pokud víte, co děláte.
Ad 2 – To se právě mýlíte, protože celá ta věc kolem adres sítí platí jenom v té síti (pokud ji chcete dodržovat). Jakmile paket projde přes hraniční router té sítě, je to prostě paket se zdrojovou a cílovou IP adresou, a nikdo neví, jak je ta síť uvnitř uspořádaná. Psal jsem vám to i na konkrétním příkladu, na kterém jste si mohl ověřit, že vaše tvrzení není platné. Pokud na něm stále trváte, tak by mne zajímalo, zda tedy adresu 216.58.209.0 je možné jako odchozí adresu použít nebo ne, zda to podle vás je adresa sítě nebo adresa zařízení.
Ad 3 – Opakovaně jsem vám vysvětloval, že IP adresa výchozí brány nemusí být z rozsahu dané sítě. Zdá se, že jste tuto informaci ještě nevstřebal, protože jste se ji ani nepokusil vyvrátit, ani s ní nepočítáte ve svém tvrzení. Např. některá datacentra přidělují koncovým zařízením IP adresy ze sítě /32, tam se vám žádná výchozí brána opravdu nevejde.

Ad 2 – Vy nejste v té koncové síti, kde paket vznikne. Vy např. provozujete nějaký server a přijde vám paket se zdrojovou adresou 216.58.209.0. Zahodíte ho na firewallu s poukazem na nějaké RFC, že má ten paket špatnou zdrojovou IP adresu? Představte si to jako reálné řešení vašeho routování a firewallu, pokud potřebujete další informace, třeba o rozsahu zdrojové sítě, tak si je zjistěte tak, jak byste to dělal v reálném případu. Asi byste to nezjišťoval v diskusi na Rootu.

Ad 3 – Proč by to mělo nějaké RFC povolovat? Potřebujete na všechno povolení RFC, nebo zvládnete něco udělat sám, tak, aby to žádnému RFC neodporovalo?

Až budete příště zase někomu doporučovat, že si má něco vyzkoušet, vyzkoušejte si to nejdřív sám. Mám tu zrovna před sebou jeden VPS. IP adresa je přidělovaná přes DHCP, já jsem nic v konfiguraci IP adres a routování neměnil, takže se nemusíte bát, že by tam bylo něco zákeřně nastavené, abych vás zmátl. Pozměnil jsem jenom prefixy sítí:

# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether aa:bb:cc:dd:48:2b brd ff:ff:ff:ff:ff:ff
    inet 111.222.114.82/32 brd 111.222.114.82 scope global ens3
       valid_lft forever preferred_lft forever
    inet6 2001:1111:2222:3333::475/128 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:feea:482b/64 scope link
       valid_lft forever preferred_lft forever

# ip route
default via 111.222.114.1 dev ens3
111.222.114.1 dev ens3  scope link

Připojený jsem tam přes SSH přes IPv4, takže myslím můžeme předpokládat, že tam IPv4 docela obstojně funguje a spojení se světem přes IPv4 ten server má.

Víte, ono nestačí přečíst si nějaké RFC, ono je potřeba taky pochopit, jak to celé funguje. Třeba takový router nebo výchozí brána, to není žádná magie. To je prostě záznam v routovací tabulce, který říká „pokud máš paket s cílovou adresou z tohohle rozsahu (nebo s libovolnou cílovou adresou v případě výchozí brány), pošli ho zařízení s touhle IP adresou. Takže když chci příslušný router nebo bránu použít, musím akorát umět poslat paket zařízení s danou IP adresou. Proč by ta IP adresa musela být ze stejného síťového rozsahu, jako jiná IP adresa toho zařízení?

Proč by musela být ze stejného rozsahu?

Patrně by nemusela, ale použití scope link na adresu gw mimo rozsah je celkem prasárna, která bude fungovat na linuxu, ale je otázka, jestli bude fungovat na jiných operačních systémech.

Nehledě na to, že pořád mluvíte o komunikaci mimo danou síť, ale komunikace může probíhat i v rámci sítě a pak budete mít samozřejmě problém se dostat na stroj s adresou broadcastu. Třeba takové ssh 1.2.3.255 v síti /24 bych řekl, že fungovat nebude, stejně jako cokoliv jiného na TCP.

Ono zahrávat si s hraničními případy, které RFC moc nedefinuje, většinou znamená koledovat si o problémy, protože každý implementátor síťového stacku si to může vyložit jinak.

Patrně by nemusela, ale použití scope link na adresu gw mimo rozsah je celkem prasárna, která bude fungovat na linuxu, ale je otázka, jestli bude fungovat na jiných operačních systémech.
Máte na podporu svých tvrzení nějaké argumenty? Proč by to měla být prasárna, proč by to někde nefungovalo?

Viděl jste někdy router? Jedno zařízení s jednou IP adresou připojené do internetu, tam bude pravděpodobně výchozí brána. Druhé zařízení s jinou IP adresou z jiného rozsahu připojené do lokální sítě. Když ten router do internetu přeposílá paket z lokální sítě nebo ze svého rozhraní, které je součástí lokální sítě, má ten paket zdrojovou IP adresu z nějaké sítě, ale jako výchozí brána se použije IP adresa z úplně jiné sítě. To je taky celkem prasárna? Nebo v čem se to liší od vašeho příkladu?

Nehledě na to, že pořád mluvíte o komunikaci mimo danou síť, ale komunikace může probíhat i v rámci sítě a pak budete mít samozřejmě problém se dostat na stroj s adresou broadcastu. Třeba takové ssh 1.2.3.255 v síti /24 bych řekl, že fungovat nebude, stejně jako cokoliv jiného na TCP.
Adresa broadcastu je ta, která je tak nakonfigurovaná, ne ta, kterou kterou uhodnete na základě masky sítě. A jak už jsem mnohokrát psal, broadcast adresu v té /24 klidně můžete namapovat na tradiční .255, protože v té síti pořád ještě zbyde dost IP adres.

Ono zahrávat si s hraničními případy, které RFC moc nedefinuje, většinou znamená koledovat si o problémy, protože každý implementátor síťového stacku si to může vyložit jinak.
Při implementaci síťového stacku jsou RFC popisující administrativní záležitosti dost nezajímavá, význam mají maximálně pro nastavení rozumných defaultů pro obslužné utility.

Ten příklad s /32 je zavádějící, protože fakticky neříká, že default gw leží v jiné síti, ale že na ens3 jsou dvě sítě, přičemž druhá /32 je síť s adresou gatewaye.
Ne, nejsou tam dvě sítě. Dvě překrývající se sítě, to by byla opravdová prasárna.

Takže ne, nedá se specifikovat gw na jiné síti.
Napsal jste chybné tvrzení a pak z něj vyvodil závěr, který z něj neplyne. Specifikovat bránu na jiné síti samozřejmě lze, není nic, co by tomu bránilo. Vyzkoušejte si to.

Rozdělím své odpovědi na sérii, ať nepoztrácíme kusy vlákna.

Patrně by nemusela, ale použití scope link na adresu gw mimo rozsah je celkem prasárna, která bude fungovat na linuxu, ale je otázka, jestli bude fungovat na jiných operačních systémech.

Máte na podporu svých tvrzení nějaké argumenty? Proč by to měla být prasárna, proč by to někde nefungovalo?

Zkuste to nastavit na Windows a můžeme pokračovat :-) Druhá věc je ta, že dost často máte různé appliance, které sice mohou být postavené na linuxu, ale ke konfiguraci přímo na úrovni CLI se nedostanete, takže vám zůstane jediná možnost, jak to nastavit v nějakém grafickém bazmeku, který na to není připravený.

Zkuste to nastavit na Windows a můžeme pokračovat :-)
Ve Windows to samozřejmě nastavit jde. Dokonce snáz než v Linuxu, protože jim nemusíte extra vysvětlovat, že router mají opravdu hledat v lokální síti.

Druhá věc je ta, že dost často máte různé appliance, které sice mohou být postavené na linuxu, ale ke konfiguraci přímo na úrovni CLI se nedostanete, takže vám zůstane jediná možnost, jak to nastavit v nějakém grafickém bazmeku, který na to není připravený.
Akorát nevím, jak jste přišel na to, že na těch 254 serverů budou instalovat zrovna nějakou takovouhle šílenost.

Jinak tomuto vašemu příkladu se říká směrování a je zcela v pořádku.
To jsem rád. Ovšem jsou tady tací, pro které je směrování něco neznámého, o směrovací tabulce asi v životě neslyšeli a pravděpodobně si myslí, že se routuje nějak podle masky lokální sítě nebo jak.

Akorát jste zapomněl zmínit, že ta "brána z jiné sítě" je "brána spadající do stejné sítě jako je síť na daném interface"
Nic takového jsem zmínit nezapomněl, protože to není pravda. Uváděl jsem tu příklad (možná jste se v něm nezorientoval, Root to zformátoval velmi podivně), kdy síť na daném interface je 111.222.114.82/32, nebo-li celou síť tvoří jedna jediná IP adresa. Do téhle sítě se už opravdu žádná další IP adresa nevejde. Jako výchozí brána je na tom počítači nastavena IP adresa 111.222.114.1, a pokud jste se ještě nesmířil s tím, že v té výše uvedené síti je jen jediná IP adresa, snad si alespoň dokážete ověřit, že IP adresa 111.222.114.1 opravdu není součástí sítě 111.222.114.82/32.

Viděl jste někdy router? Jedno zařízení s jednou IP adresou připojené do internetu, tam bude pravděpodobně výchozí brána. Druhé zařízení s jinou IP adresou z jiného rozsahu připojené do lokální sítě. Když ten router do internetu přeposílá paket z lokální sítě nebo ze svého rozhraní, které je součástí lokální sítě, má ten paket zdrojovou IP adresu z nějaké sítě, ale jako výchozí brána se použije IP adresa z úplně jiné sítě. To je taky celkem prasárna? Nebo v čem se to liší od vašeho příkladu?

Ano, viděl jsem router. Můžete na mne mluvit třeba jazykem Cisco IOS, Juniper Junos, nebo HP Comware, což pokrývá asi 99 % trhu všech zařízení, kterým se dá říkat "router" nebo "L3 switch".

Jinak tomuto vašemu příkladu se říká směrování a je zcela v pořádku. Akorát jste zapomněl zmínit, že ta "brána z jiné sítě" je "brána spadající do stejné sítě jako je síť na daném interface"

Ten příklad s /32 je zavádějící, protože fakticky neříká, že default gw leží v jiné síti, ale že na ens3 jsou dvě sítě, přičemž druhá /32 je síť s adresou gatewaye. Takže ne, nedá se specifikovat gw na jiné síti.

Jen bych upozornil na můj vstup do vlákna, kdy jsem mluvil o tom, že z diskuze vynechávám specialitky typu /23 nebo /32, anycast apod.
Takže závěr je, že to nejde, s výjimkou případů, kdy to jde…

diskuze byla o něčem jiném, Vy se jí snažíte stáčet směrem, který Vám vyhovuje
Diskuse byla o tom, zda se do rozsahu /24 vejde 254 serverů. Diskusi stáčím tím směrem, že to jde – což je myslím celkem pochopitelné, když se diskutuje, obvykle lidé uvádějí argumenty na podporu svých tvrzení.

Pokud to opravdu chcete podložit, ukažte mi funkční příklad s nastavením default GW (jediné položky směrovací tabulky, abych to upřesnil) mimo rozsah sítě na /24, o který jsem žádal. Rád se poučím.
Už jsem vám tu podobný příklad uváděl, to si to fakt nedokážete odvodit sám? Nebo si přečíst manuál?

Začněte s tím, že máte na zařízení přidělenou jen IP adresu 10.0.0.100 a routu do 10.0.0.0/24 přes 10.0.0.1. Žádnou jinou IP adresu ani routu nastavenou nemáte. Chcete nastavit že výchozí brána je 192.168.123.1.

Na Linuxu:

ip route add 192.168.123.1/32 dev eth0
ip route add default via 192.168.123.1 dev eth0

Na Windows:

netsh interface ipv4 add route 0.0.0.0/0 "Ethernet" 192.168.123.1

Ano, na Linuxu je to trochu zvláštní, že musíte předem explicitně uvést, že ten router je fakt v místní síti, ale to není nic, na co by se nedalo přijít.

To ale není to, co po vás tazatel chtěl. Co vy uděláte je to, že na L2 síť dáte další L3 síť a do té pak směřujete default, což je v pořádku. Ten interface má dva L3 rozsahy, přičemž adresu má pouze z jednoho, což nesplňuje požadavek toho, co chtěl předřečník.

už to vaše "Žádnou jinou IP adresu ani routu nastavenou nemáte." není pravda, protože tu routu jste uvedl hned na prvním řádku příkladu.

@DgBd, 15:44: Připadá mi, že se tak soustředíte na to, abyste mi oponoval, že už vám nezbývají síly ještě se držet tématu diskuse a občas už ani na to, aby váš komentář byl ještě příčetný.

Co vy uděláte je to, že na L2 síť dáte další L3 síť a do té pak směřujete default, což je v pořádku.
Celá ta diskuse začala větou z článku: „Jsou úplně stejné a je jich přesně 254, takže se nám vejdou do jednoho IP rozsahu.“ Myslím, že je z toho zřejmé, že se bavíme o L3 síti. L2 do toho není potřeba tahat, pokud budeme předpokládat, že na úrovni L2 to realizovatelné je. Představte si třeba několik propojených L2 switchů, každý z těch serverů bude zapojen do jednoho portu switche a navíc bude ještě do jednoho portu připojen router. Takže realizovatelné to myslím je a dále se snad můžeme bavit o L3 síti.

Ten interface má dva L3 rozsahy, přičemž adresu má pouze z jednoho, což nesplňuje požadavek toho, co chtěl předřečník.
Nevím, jak definujete pojem „interface má rozsahy“. Podstatné je, že to rozhraní má IPv4 adresu z jednoho rozsahu, a jako výchozí bránu má nastavenou IPv4 adresu, která není v rozsahu L3 sítě, jejíž je to zařízení součástí. Tedy je možné realizovat přesně to, o čem je celou dobu řeč – 254 serverů v jedné /24 L3 síti, dvě krajní adresy sítě rezervované, a router s IP adresou, která není součástí té /24 L3 sítě. Pokud chtěl tazatel něco jiného, pak je to problém jeho požadavků, ne problém, který by bránil řešení té situace. Ostatně celá diskuse začala právě tím, že Pavouk něco předpokládal, půlku těch předpokladů ani neuvedl, ale hlavně ty jeho předpoklady nemusí být splněné.

už to vaše "Žádnou jinou IP adresu ani routu nastavenou nemáte." není pravda, protože tu routu jste uvedl hned na prvním řádku příkladu.
A tady už se dostáváme k tomu, kdy píšete z cesty. Když se popíší výchozí podmínky, a pak se popíše změna, která se po té udělá, je logické, že po té změně už neplatí ony výchozí podmínky. Když vám někdo napíše „máte červený plot, a ten natřete na zeleno“, je dost bláznivé reagovat na to tvrzením, že přece není pravda, že je plot červený, když ho pak natřete na zeleno. Je potřeba rozlišovat, že plot na začátku červený je, a teprve po natření bude zelený. Stejně tak v mém příkladu je výchozí situace taková, že máte nastavenou jenom jednu jedinou routu – do sítě 10.0.0.0/24. To je výchozí stav, máte nastavenou jenom tuhle jedinou routu a žádnou jinou – a teprve posléze tam začnete přidávat další routy (čímž se ten výchozí stav samozřejmě změní). Už to chápete? Ano, mohl jsem ten příklad popsat úplně od nuly, že nemáte přidělenou žádnou IP adresu a nastavenou žádnou routu, ale předpokládal jsem, že tady diskutují lidé, kteří si umí ten výchozí stav představit a možná dokonce nakonfigurovat. No a způsob, jak to nastavit, jsem popisoval proto, abyste si to mohli vyzkoušet. Protože tady byli tací, kteří nevěřili tomu, že to jde, a nevěřili ani když jsem popsal ten výsledný stav. Takže jsem vám napsal krok za krokem příkazy, abyste si mohli do virtuálu nainstalovat Linux nebo Windows a na vlastní prsty a oči se přesvědčit, že to doopravdy je možné.

Já myslím, že jsme si své postoje už vyjasnili, ať si z toho každý vybere to, co uzná za vhodné.

Na rozdíl od Vás nemlžíme.
Přečtěte si co, jsme kde napsali a uvedli.
Vy stále nechcete vidět, že máme de facto 2 budovy. Jedna je administrativní a to je ta, kterou vidíte a o které pořád píšete, že na tom pozemku byla voda. Ano, to tak je. Potom máme datový sál, který je na pozemku, kde voda nikdy nebyla, ale to vy vidět nechcete.
Máme pozemek ještě i směrem k zámku, což je o další desítky metrů výše. Takže máme přístup, máme zásobování. A níže máte vysvětlené jak se zásobováním nafty pro diesely.
Do detailu vzato máme druhé datacentrum a pojedeme tam odsud :-) .

Tady ještě dám kopii toho, co jsem napsal v jiném příspěvku před chvilkou.
Trafostanice, která je zaokruhovaná a je opět nad historickou vodou. A kdyby nic, tak budeme mít 3 linie motorgenerátorů. 1 bude primárně zálohovat kompletně celý vstup a bude celá uvnitř budovy. Jen doplňování nafty a vzduchu bude vyvedeno vysoko nad budovu. Druhá a třetí linie motorgenerátorů bude napájet vždy jednu (pod podlahou) nebo druhou (pod stropem) napájecí větev. Část generátorů, která utáhne 100% provozu, bude uvnitř a část (taky na 100% zátěže) venku (vysoko a daleko od vody). V každém případě má vše přístup z druhé strany (60 metrů vysoký kopec), kde žádná voda nebude. Generátorů bude celkem 5 na 3 různých větvích. Všechny generátory jsou projektované na nepřetržitý provoz, každý má dostatečný výkon na 100% provozu a přímo v sobě mají nádrže na 12 hodin 100% provozu (vynásobte krát počet generátorů) plus budeme mít ještě další naftové hospodářství s další zásobou. Všechny budou mít možnost doplňování ještě mimo budovu... Takže v tomto směru problém není. Generátory máme tedy stavěné v režimu N+ 2(N+1). Z hlediska TIER potřebujete je 2N, my jsme si tam přidali ještě jednu celou řadu navíc.

Uvnitř budou UPS - jedna řada pro napájecí větev pod podlahou a druhá řada pro napájecí větev pod stopem. UPS jsou 2(N+1), přičemž při 100% zátěži mají vydržet nejméně 15 minut.

Celé je to koncipované tak, že budou 2 napájecí větve, kompletně oddělené, nikde se nekřížící a nikde se nepotkávající. Napájení z obou větví se potká až v serveru (každá větev do jiného zdroje). Všechny kabely máme nehořlavé a jedna větev vede v požárně odolné podlaze a druhá větev v požárně odděleném stropním podhledu. U požární odolnosti vyžadujeme 90 minut. Takové řešení v ČR asi nikde není.

Snažíme se nic nepodcenit a vše udělat s maximální péčí.

Byl jste někdy v této lokalitě? Viděl jste někdy kopec, kde je zámek a je o 60 metrů vyšší? Víte, že ten kopec je přístupný a ze všech stran a kdykoliv?

Když dojdou argumenty, tak se snažíte být vtipnější :-)

V jiných příspěvcích jsem napsal jak to bude s naším elektro hospodářstvím a když budeme mít 3 linie motorgenerátorů, které budou složeny z 5 strojů a každý na 12 hodin provozu (při 100% zatížení) plus další doplňování... a s možností přístupu...

Nechám toho, protože bych se opakoval a s anonymními příspěvky, které nemají argumenty je těžké bojovat. Respektive bojovat lze, ale je to ztráta času. Jdu se věnovat klientům a službám, které nabízíme.
Včera jsme spustili nové virtuální servery VPS ON (OpenNebula), které jsou předchůdcem WEDOS Cloud... Nyní testujeme nový, nejrychlejší webhosting na HPE Moonshot. Prostě jdeme dopředu.

Tak když to říkáte, tak Vás při tom nechám. Pořídíme si ještě vrtulník. Matematika je jiná, ale co se dá dělat... Vy jste odborník na všechno. Včetně vody, včetně napájení, včetně geografických záležitostí a výškopisu na Hluboké. Já se vrátím na Mars :-) .
Nebudete věřit, ale o vodě něco vím a o povodních také. A nebavíme se tady o týdnech, ale to není podstatné. My jsme na ně připraveni.
Nebo to chcete zopakovat, že máme zálohu přímo v generátorech na 5 x 12 hodin na 100% provozu, ale ta tam nikdy nebude, protože vždy musí být rezerva. Plus k tomu bude další záloha na dalších mnoho dní provozu a plus máme přístup přes kopec, který je o 60 metrů vyšší. Máme tam přístup jak autem, tak i vrtulníkem (když tedy chcete :-) ). A tam je možnost doplňovat cokoliv za běhu...
Všech 5 motorgenerátorů je speciálně vybraných na trvalý a nepřetržitý provoz. Ano, přesně tak. Výkonem a parametry jsou stavěné na plný provoz. A ještě bych ke generátorům napsal jednu zajímavost, ale Vám to nemá smysl už vysvětlovat.
A když tedy budete plánovat, že vše zdvojené (a motorgenerátory ztrojené) selže, tak máme druhé datacentrum. A tam to bude zdvojené taky. Vy z nás máte nějaké špatné sny. Pokud by jste byl zákazník, tak máte možnost volby a nebudete tady ztrácet čas tím, jak reagujete. Asi v tom bude něco z oboru :-) Nebojte, na rozdíl od Vás spím a budu spát klidně. Děláme vše s čistým svědomím a každému to rádi ukážeme.

Ano, vše je to velmi komplexní a náročné a proto se vše snažíme zdvojit. Něco přímo v jednom datacentru, vše ostatní v druhém datacentru.

Okruhy máme 3x. Generátory také řešíme jako mnohonásobné řešení, které navíc pravidelně testujeme. 1x týdně vizuální kontrola, 1x týdně potom jiný den test a 1x měsíčně ostrý test, kdy skutečně shodíme hlavní jistič. A tak by šlo pokračovat.

Pokud jde o olej, tak i tahle hlediska jsme si i hledisko požární ochrany brali na zřetel. Olej se vznítí až při vysokých teplotách je ve IV. třídě hořlavin (a prakticky už na hranici s nehořlavými látkami) a jen tak se nevznítí. Ale stejně všemu chceme předejít. Vany budou uzavřené a tak tam nebude mít přístup kyslík. Tak tam nemá co hořet, ale i tak... . V datacentru najdete jen nehořlavé kabely. Máme v každé místnosti 3 různé požární sekce s odolností na 90 minut (pod podlahou, pod stropem a mezi). Co dále? Chceme tam mít sníženou hladinu kyslíku na 15%, kdy už nehoří nic. Určitě bych si vzpomněl na další záležitosti. Ve výsledku je naše řešení bezpečnější, než klasické datacentrum plné hořlavých kabelů v jednom společném prostoru, kde se pomocí vzduchotechniky honí tisíce m3 vzduchu (a tím kyslíku) za hodinu...
Přesně takhle to je a věřte, že to tak chápou i hasiči. Samozřejmostí je i automatický hasící systém, včetně trojnásobné detekce.

Řešíme-li historii, tak máte pravdu, ale nezapomínejte na několik zásadních věcí. Například - u nás hostuje tolik služeb (například hostingů máme 3x tolik, než další hosting v pořadí) a tak je o jakémkoliv problému více slyšet. Máme klienty, kteří jsou zvyklí komunikovat veřejně a tak se o čemkoliv píše veřejně. Máme hodně nepřátel, kteří se na všem velmi přiživují. Když si vzpomeneme na některé totální výpadky (i mnohahodinové) jiných, tak se o nich nenapsalo prakticky nikde (a je jich více). Ale nechci tady psát o jiných. To neděláme. Dále třeba berte v úvahu i to, že jsme odstartovali před 7 lety a za tu dobu neuvěřitelně rosteme a budujeme. Ke všemu se stavíme čelem a z každé nepříjemné situace se poučíme. Ke všemu jsme si prošli obdobím, kdy jsme třeba byli pod silnými útoky a díky tomu máme DDoS ochranu. Potom jsme měli problém s přetěžováním webserverů kvůli napadeným CMS a tak jsme udělali IDS/IPS ochranu. Vše řešíme.

Tady někdo psal, že se bavíme o záloze v případě nějaké velké vody? To jsem nikde nikdy neřekl. Na to máme jiné řešení.

V každém případě jsem řekl, že máme napájení z trafostanice, plus jsme na stejných svorkách jako MVE a tudíž elektřina (technicky a logicky) jde z MVE k nám.

V budově budeme mít 2 linie napájení, obě na 100% zátěže. Vše plně redundantní a plně oddělené (fyzicky, požárně) a nikde se to nekříží a nikde se to nepotká. Vše je kompletně včetně UPS 2 x N+1 a motorgenrátorů 2 x N (na počátku dokonce 2 x 2N). Jedna linie napájení bude pod protipožárně odolným stropem a druhá pod podlahou. Vše skutečně oddělené.

Vzhledem k tomu, že jsme si vědomi toho, že tam nemáme další napájení, tak jsme si přidali další linii a to další oddělenou sadu motorgenerátorů. Takže tento motorgenerátor nám dodává elektřinu v případě výpadku trafostanice (nebo chceme-li se bavit o MVE). Docílíme tím toho, že jsme připojeni na MVE, trafostanici (která je zaokruhovaná na VN) a když tohle nebude fungovat, tak naskočí hlavní generátor. Když selže, tak máme další 4, které mohou převezmou zátěž. Z těch 4 jsou všechny (tedy kterýkoliv z nich samostatně) schopné krátkodobě (do 200 hodin ročně) převzít kompletně provoz celého datového centra. Takže ohrožení provozu bude v situaci, když umře MVE, zaokruhované VN, trafostanice, hlavní motorgenerátor a následně 4 další. Rozumíme si? Mimořádně drahé řešení, ale chceme to udělat pořádně.

Vy z nás musíte mít hodně velký komplex a máte s námi asi hodně velký problém. Co se dá dělat. Kdo chce, tak tomu se to dá vysvětlit a kdo nechce, tak mu nepomůže ani plánky, které si sám našel...
Takže na tomto odkazu je jasně vidět, že trafostanice, kterou máme u nového datacentra má přívody z různých směrů. Tečka. To tam je červené na modrozeleném.
Další debaty jsou zbytečné.

O tom jak to budeme mít zálohované a jak tam bude 5 motorgenerátorů jsem psal a nebudu to vysvětlovat znovu, protože tohle je marné a zbytečné. Sám jste se usvědčil z toho, že tady tvrdíte nepravdy.

A tady jste jen ukázal jak se v celé situaci vyznáte... To co uvádíte zde je naše stávající datacentrum a tam máme svoji vlastní trafostanici, která má smyčku tam a zpět a není zaokruhovaná. Ale to je jiné datacentrum, než si myslíte. Ach jo. Zbytečná ztráta času.

A když už jsme u toho, tak do stávajícího datacentra budeme mít 2 nezávislé přípojky ze dvou různých stran, ze dvou různých trafostanic a celé to bude jištěné 2 různými motorgenerátory.
Co víc dodat?

Na další Vaše zbytečné a anonymní podněty už nebudu zřejmě reagovat, protože mám jinou práci. Děkuji za pochopení.

U nás na webu to bylo. Měli jsme to i na facebooku a twitteru. Koupit si to mohl každý.

Je smutné, že píšete to, co píšete a neumíte se ani podepsat. Za svůj názor se přeci nemusíte stydět.

Předpokládám, že naši zaměstnanci mají jinou práci, než tady mínusovat. Určitě nechodí do podobných diskuzí zabíjet čas, ale věnují se zákazníkům a službám, které nabízíme. Možná to tak děláte u vás a proto se zmůžete jen na podobné útoky.

Plácáte páté přes deváté. Bazarový hardware jsme nikdy neměli. Vše máme nové. Koupili jsme vždy vše od Fujitsu nebo HPE. A na tom jedou všechny naše služby. Nyní jsme koupili 254 serverů něco přes rok starý a chceme je nabídnout jako dedikované servery. Nic na nich není špatného a jsou v záruce. Předpokládám, že tolik nového hardwaru jako u nás na mnoha místech v ČR nenajdete. Určitě to nebudou desítky míst... A to nemluvím o tom, jaký hardware používáme. Počínaje současnými servery a až po HPE Moonshot. Takže si své narážky můžete psát jinam. Děkuji.

Kryt jsme koupili v roce 2010 a je skutečně 40 let starý, ale to na něm nic nemění a v záplavové oblasti není. Nyní stavíme druhý a děláme to s maximální péčí. Věřte tomu, že jsme si to postavili za svoje vydělané peníze, bez úvěrů a dotací. Nevím kde berete tvrzení o dumpingových cenách, ale to už je takové zoufalé...

Nestydíme se za to, co máme a za to, jak to děláme. Každému se dokáži klidně podívat do očí. Musíme Vám hodně vadit, když takhle píšete a za svůj názor se stydíte i reálně podepsat. Nám to nevadí. Děláme svoji práci dobře a chceme dělat ještě lépe.