reality

odběratel č. 5293: Server Reality.CZ, s.r.o.

Servery/VM:

TYP	IP	jmeno	funkce	ssh port zvenci
OVZ	192.168.55.51	ovz_realitycz_mariadb? / id 5507	db	10021
OVZ	192.168.55.52	ovz_realitycz_nginx? / id 5502	nginx	10022
OVZ	192.168.55.53	ovz_realitycz_logger? / id 5520	logger	10023
OVZ	192.168.55.55	ovz_realitycz_vpn? / id 5505	vpn	10022 (na druhe IP)
OVZ	192.168.55.54	ovz_realitycz_8? / id 5508	bind	10024
OVZ	192.168.55.11	backend-11.reality.internal	backend	10031
OVZ	192.168.55.12	backend-12.reality.internal	backend	10032
OVZ	192.168.55.13	backend-13.reality.internal	backend	10033
OVZ	192.168.55.14	backend-14.reality.internal	backend	10034
OVZ	192.168.27.102 / 172.55.0.13(vpn)	db-backup.reality.internal	db slave	zabehlice/BH1
OVZ	192.168.27.103 / 172.55.0.14(vpn)	db-backup-delayed.reality.internal	odlozeny slave	zabehlice/BH1
OVZ	192.168.55.59	alpha.reality.internal?	devel pro soucasny web	casa clu
OVZ	192.168.55.61	devnodejs.reality.internal	testovaci nodejs	casa clu
OVZ	192.168.55.62	elastic.reality.internal	testovaci elasticsearch	casa clu
OVZ	192.168.55.63	smtp.reality.internal	smtp server pro mailling	casa clu
OVZ	192.168.55.64	smtp.reality.internal	smtp server pro errory	casa clu
OVZ	192.168.55.65	nodejs-prod.reality.internal	produkcni aplikacni server pro m.reality.cz	casa clu
OVZ	192.168.55.100	ovz_realitycz_nginx?	neplovouci IP pro master instanci proxy	casa clu
OVZ	192.168.55.101	ovz_realitycz_proxy-stby?	neplovouci IP pro stby instanci proxy	lh4
OVZ	192.168.55.66	ovz_realitycz_elk	analyza logu proxy - test	lh4

Pro ucely sdilene komunikace byl zalozen ucet na Trello.

https://trello.com/

linux@uvt.cz

1:6eO/uaXglYagoeGhpoWR6dA=

Popis funkcionality:

Heslo na vsechny VM :

root	1:oaD4+PjxrLunsMk=

Postupy pri vypadcich - restart serveru:

Reality zadaji spise konzistentni stav nez rychle obnoveni funkcionality. Zejmena se to tyka stavu databaze. Proto automaticky start mysqld je na db serveru zakazan - poustet se ma rucne, a to az si jsme jisty, ze databaze je v poradku. Pokud vime, ze neni (stroj byl vypnut natvrdo nebo se mysql neshutdownovalo pri vypnuti), je treba spustit jeji kontrolu. Pokud vime, ze mohou byt nacate souborove systemy, bezpodminecne je zkontrolovat na backendech a na db.
Pro kontrolu db je udelan script, /root/test_mysql (pridal jsem tam test_mysql_new, je rychlejsi nez puvodni, funguje a pousti se stejne. Vysvetleni uvnitr scriptu. Denis.). Spousti se "./test_mysql /data/mysql" pri _vypnute_ databazi, databazi spoustet az po dobehnuti kontroly (muze trvat i 45 minut).

Na backendech v adresari /www/soap14test je script soap14-testing. Ten slouzi pro kontrolu vkladani nabidek realitkami. Pri spravnem fungovani vypisuje neco jako "OK: Nabidka 555-JNFUUE uspesne odeslana". Je treba to vzdy zkontrolovat po nahozeni db nebo backendu, a nginx prepinat do "normalniho" chodu jen v pripade, ze script zafunguje.

Cely postup po kompletnim vypadku je tedy nasledujici:
- prepnout nginx do chyboveho modu (pokud se neprepnul sam).
- zkontrolovat FS
- nahodit db stroj a zkontrolovat v pripade potreby tabulky (realitycz_1)
- spustit logserver a dns (realitycz_3, realitycz_8)
- nahodit backendy a zkontrolovat SOAP (realitycz_backend_11 - 14)
- kontaktovat reality na adrese bosson v(e) reality.cz se strucnym popisem toho, co se stalo.

Na svem pocitaci (10.0.10.176) mam ssh klic pro pripad, ze by zmenenili heslo root (obcas to delaj).

Munin

Munin realit je dostupny na

https://munin.reality.cz:4443/

munview

1:OggBUFYuOTlg

Postupy pri vypadcich - dlouhy vypadek napajeni atp:

Pro pripad dlouhe nedostupnosti webu reality.cz (cela aplikace vc. proxy) je pripraven failover web, coz je proxy server na LH2 v sitelu. V tom pripade je potreba na master DNS (dns1.reality.cz - umisten na clusteru v sitelu) - zmenit zaznam pro reality.cz, jak A, tak AAAA. Oba zaznamy jsou zakomentovane a pripravene v zone (/var/named/masters/reality.cz), staci odkomentovat a zakomentovat puvodni, pritom se neinkrementuje ani serial number, to se poresi samo viz dale. Nasledne se musi zona prepodepsat kvuli dnssecu a reloadnout binda. Vsecko dela skript /usr/local/script/resign-transfer-zones.sh.

Proxy na failover webu je nastavena tak, ze vse proxuje na primarni proxy v case, v pripade nedostupnosti zobrazi za 5s pripravenou chybovou stranku vc. jejich mutaci pro soap atp. Cili jakmile se provoz vrati do normalu na masteru, proxy zacne normalne zobrazovat web, neni tedy potreba to hned prepinat zpet.

VPN a LDAP auth

Do prostredi jsem jim doinstaloval VPN server s LDAP auth, taktez pam_ldap na vsecky VM vyjma DNSek. VPN je pristupna na IP 109.205.76.51. Nastaveni VPN je ulozeno v prvni priloze teto stranky (je nutne byt prihlasen, aby se zobrazila).

Pro prihlaseni do VPN pouzivame uzivatele uvt:

uvt	1:MhMcS08iKj4rFns=

sudoers v LDAPu

[+]

MySQL servery:

V prostredi RCZ bezi celkem 3 mysql servery. V casablance na clusteru bezi primarni db, ktera se replikuje do Zabehlic (backuphost1.zab.cldn.eu) na 2 repliky. Jedna replika je ontime, kdy je pozadovane zpozdeni co nejmensi a pouziva se jako souborova a logicka (dump) zaloha. Druha replika, nazyvana delayed, je replika, kde je umele udrzovane zpozdeni zhruba 1h. K tomuto ucelu na replice bezi nastroj ze skupiny percona-tools, a to sice pt-slave-delay. Obe repliky se pripojuji jako VPN klienti do site na casablance a z te jsou take dostupni.

Zalohy MySQL

Protoze je pozadovana 100% obnovitelnost db, dela se v 10:00 pomoci xtrabackup nastroje souborova zaloha do /data/binbak a ve 22:00 se dela dump vsech tabulek. K pokryti doby mezi zalohami se ukladaji binlogy na masteru zhruba 10 dni zpetne. Ty se take kazdou hodinu rsyncuji na slave (pouze 3 dny stare binlogy), takze v pripade havarie je na slave dostupna binarni zaloha a potrebne binlogy, i kdyby je nekdo omylem smazal z masteru. Ty se na backup nezalohuji (zalohuji se z masteru)

Ke snadne obnove chybnych zasahu do db (nechtene smazani zaznamu atp) slouzi delayed replika. Pokud administrator udela chybu a zahy ji zjisti, je mozno obnovit smazane zaznamy z delayed repliky, za predpokladu ze zmena jiz byla zpozdene zreplikovana.

Pristupy na MySQL

Defaultni je pristup bez hesla na lokalni db pod userem root.

Ostra DB:

root	localhost	----
root	172.55.0.13 (db-replika2)	1:HCoDNAV2fjc0MUY=
replicator	172.55.0.13	1:lKOS4Obh4+Lji73R	replika z db-backup
replicator	162.168.55.254	1:FyARampnYGFkFyIfUg==	replika z db-backup-delayed

Delayed replika:

root	localhost	-----
delayer	localhost	DeLAWA18	PROCESS, REPLICATION CLIENT, SUPER

Replika:

root

localhost

----

Overeni konzistence repliky, databaze nebo pouze jedne tabule je popsano zde: https://tiki.uvt.cz/tiki-index.php?page=Replication+consistency+check&highlight=pt-slave

DNS servery:

Reality presli se spravou DNS pod nas, takze jsou vytvorene 3 DNS servery ktere spravujeme. Jeden z nich je virtual u spol. Wedos, info, pristupy atp. Lubos Bielak, taktez spravu vsech zon na NS.

nazev	IP	OS/NS	umisteni	pristup
dns1.reality.cz	109.205.75.62 / 2a00:1238:4:27::2	SL64 / Bind	bosson/sitel	ssh 10002 - root:1:7f2Ji43aztn6ytu8
dns2.reality.cz	37.157.195.232 / 2a02:2b88:2:1::1ce7:2	Debian 7.1 / Knot DNS	Wedos - Hl.n.Vltavou	ssh 10002 - root:1:q5vv6+2QiKva
dns3.reality.cz	109.205.76.14 / 2a00:1238:3:55::54	SL64 / Bind	bosson/casa	ssh 10024 - root:1:ub7Nzc7JqLb4

DNSSEC & TLSA

Zona reality.cz a cenmap.cz jsou zabezpeceny dnssecem. Zona cenmap.cz byla zkusebni, pred nahozenim na reality.cz.

zmena v zone reality.cz
1) prihlasit na dns1.reality.cz
2) zmenit pozadovane v nepodepsanem zonovem souboru (/var/named/masters/reality.cz), pritom neni potreba menit serial, incrementuje ho skript, viz dalsi krok
3) spustit /usr/local/scripts/resign-transfer-zones.sh , ktery znovupodepise domeny a pritom incrementuje serial a reloadne binda, coz spusti standartni redistribuci zony na slave servery.

TLSA (DANE) je z duvodu nasazeni Let's Encrypt certifikatu zruseno.

TLSA
-V zone reality.cz je nastaveno nekolik TLSA zaznamu pro certifikat na ruznych domenach (www, usapi, uzivatel atp). Pokud se certifikat bude menit, je potreba TLSA pregenerovat (viz klient Cheque Dejeuner). Je potreba dat pozor na wildcardy, viz nize.

dnssec, tlsa a wildcard
Pri nastavovani TLSA byl nalezen zrejme bug v bindu, kdy pokud je zapnut dnssec, existuje TLSA RR pro zaznam, ktery ale neexistuje a je na nej pouze wildcard, tak tento zaznam nebude bindu znam, takze pokud potrebuji TLSA pro www.reality.cz, musi existovat zaznam www jinak nez pouze wildcardem. Pokud by to byl wildcard, pak www.reality.cz nebude resolvovatelne (stalo se).

Mailling system, dkim, dmarc

V prostredi serveru RCZ je virtualni server smtp, ktery ma za ukol starat se o odesilani posty. Uvnitr bezi 2 instance postfixu, jedna main (nebo take smtp) a druha "smtperr".

Main instance funguje jako odesilac mailu z realitnich serveru pro bezne zakazniky, instance smtperr je nastavena pro odchod chybovych emailu z prostredi reality.cz

Vypis front obou instanci lze pomoci allmailq, nebo vice viz https://tiki.uvt.cz/tiki-index.php?page=ovz_ebrana_mailer-1

Dkim

smtp instance podepisuje emaily dkim podpisem, kteryzto demon bezi primo na smtp, smtperr emaily nepodepisuje, aby v pripade velkeho mnozstvi emailu zbytecne nezatezovala dkim server.

Dmarc

Dmarc je technologie, ktera spojuje spf a dkim. Jednak overuje podpid mailu dkimem a druhak overuje, ze je skutecne podle spf odeslan z te domeny. Je to jen DNS zaznam.

Kvuli posileni duvery mailu a take omezeni seznam.cz na hromadne maily bez dkim, je na proxy serveru nasazen opendkim server, na ktery je smerovan milter z postfixu ze vsech backendu, a je na nem nastaveno podepisovani pro domeny reality.cz a prislusny zaznam je nastaven v dns zone reality.cz. Pokud by opendkim nejel, maily by cekali ve fronte na backendech s temporary chybou.