Nejen prací je živ člověk, každá generace má nějakou svoji ikonickou hudbu, jednou z hudebních legend jsou pro nás Midi Lidi, 15. června 2016 vychází nové album, podpořte ho.
Není to hudba pro každého, ale dejte tomu šanci: “Give Masterpiece a Chance!“.
Děkujeme za tu radost, MOJEservery.cz.
► paypal/kartou – LP/CD/DIGI (worldwide) midilidi.bandcamp.com
► dobírka LP (jen ČR) goo.gl/9uPdqx
► dobírka CD (jen ČR) goo.gl/HCDQ5P
Úspěšně realizováno!
Pro zákazníka 1. AROMATERAPEUTICKÁ KH a.s. jsem provedli konsolidaci lokální počítačové sítě (LAN), připojení první vzdálené pobočky pomocí technologie VPN, napojení na VoIP ústřednu, konfigurace firewallu a zavedení základní bezpečnostní politiky. Pokračování textu Realizováno! Konsolidace LAN, výstavba VPN pro AROMATERAPIE a.s.
Jak funguje Windows Subsystem for Linux(WSL), proč mohou nativní binární ELF64 aplikace z Ubuntu běžet na Windows 10 beze změn, základní popis principu WSL pro “laik geeky”.
Líbilo se?
Zanechte like, komentář, odběr kanálu, sdílejte, děkujeme.
MOJEservery.cz
Dne 6. 6. 2016 proběhl na půdě ČVUT FEL Praha CESNET seminář o protokolu IPv6, který se dostává po 20 letech jeho existence ke slovu v souvislosti s vyčerpání zásob adres protokolu IPv4.
Výborná akce, děkujeme!
Kdo nestihl má možnost díky skvělé práci avc.siliconhill.cz vše dohnat ze záznamů na @Youtube, odkaz na playlist dole.
Přednášející:
Pavel Satrapa – IPv6: Jak jsme na tom
Tomáš Podermański – Strasti implementace CGN
Ondřej Caletka – Dual stack jako řešení přechodu?
Tomáš Košňar – Implementace a monitoring IPv6 v e-infrastruktuře
Martin Pustka – Slasti a strasti IPv6 v univerzitní síti
Matěj Grégr – Jak se měří IPv6?
Martin Samek – Jak si Wi-Fi poradí s IPv6 (Srovnání Google Doc)
Jiří Průša – IPv6 a veřejná správa
Ondřej Caletka – Role síťové masky v IPv6
František Vaněk – Nasazení IPv6 na UCEEB ČVUT
Ondřej Surý – Můj život na IPv6-only
Hotel stack platformaHotelové prostředí v moderním pojetí dnes reprezentuje komplexní, živý a náročný „organismus“, dobře naladěný hotel poznáte během okamžiku, orchestrování hotelů dnes představuje manažerský kolotoč a bez kvalitního informačního zázemí se nelze obejít.
Jaká je však skutečnost technologického zázemí dnešních hotelů ?
Z naší praxe za 20 let pohybu v hotelovém segmentu musíme bohužel konstatovat, že zcela tristní !
Staré dosluhující systémy, bez podpory aktualizace software, často zcela bez zálohovacích nástrojů pro ochranu dat, hardware prvky za morální životností netrpělivě čekající na „křemíkové nebe“, v provozu často dva i více fyzických serverů, každý s využitím na zátěže ~10%, energetická efektivita škoda mluvit a pravidelný restart 1x denně/týdně je dobrý standart. A co sítě ? Zde začíná teprve velmi slušný cirkus, plochá LAN, chaoticky vyzařující a vzájemně se rušící hotelové wifi, často sporadicky fungující wifi pro hosty, vouchery?, tickety? sms platby? haló je rok 2016, bezpečnost hotelové sítě, firewall, VPN, propojení lokalit, nic, nic, jen sprostá slova a VoIP, magie, která v komerčním prostředí funguje zcela spolehlivě, jen hotely mají 20+ staré ústředny, čest jejich památce, proč když začít je tak snadné.
Zní vám to povědomě ?
Platforma hotel stack představuje naši evoluční odpověď na konsolidaci IT prostředí hotelových provozů, ucelená modulární platforma odbavující veškeré služby hotelu od datové konektivity pomocí metalických i optických sítí, bezpečnostní firewall s VPN, řešení pro výkonné bezdrátové sítě s centrálním řízením wireless controllerem, nástroje pro virtualizaci serverů a hotelového software, integrovanou moderní VoIP ústřednu s tarifikací a okamžitému nasazení, systém zálohování a obnovy dat, dohledový kamerový systém s podporou IP kamer, vše doručováno při vysoké efektivitě, modulárnosti, energetické úspoře a chráněno záložním zdrojem UPS s přepěťovou ochranou.
Hotel stack Router, Switch
Hotel stack virtual serverVirtualizace serverů a operačních systémů přináší efektivní využití Vašich hardware prostředků , k čemu mít 5x fyzický server a každý využívat každý na 20%, když je možné jedno železo a vytížit ho plně, úspory značné v pořízení i provozu.
Reálná agregace z praxe je až 10x virtuálních strojů na 1x fyzický server.
Virtualizační technologie VMware server/KVM.
Možnost přechodu do cloud prostředí datacentra ! Nechcete udržovat vůbec vlastní serveru fyzický server? Lze hostovat virtuální servery v našem datacentru. Nabídka: 4x CPU, 16GB RAM, 300GB HDD SSD, Windows 2012R2 Cena: 1650Kč / měsíčně
Používáme výhradně certifikované servery Dell, IBM, Supermicro, Thomas Krenn, redundantní komponenty, RAID pole.
Podporujeme operační systémy:
Podpora pro hotelový software dodavatelů:
Připravené scénáře k okamžitému nasazení na „jedno kliknutí“:
Hotel stack VoIPModerní VoIP ústředna, levné hovory do celého světa.
Hotel stack zálohování, kamerový systémZálohování konfigurace celé platformy (router, switch, virtualizační server včetně virtuálních strojů), možnost synchronizovat zálohy na externí zrcadlo pro zvýšení bezpečnosti.
Kamerový systém představuje jednoduchý nástroj pro online 24/7 monitoring a ostrahu objektů, provozů, podpora pro IP kamery s vysokým rozlišením v kombinaci s VPN technologií poskytující zařízení hotel stack router je možné přenášet a ukládat obraz ze vzdálených lokalit (spojení dva a více hotelů).
Hotel stack UPSZálohované napájení energie pro platformu, ochrana přepětí sítě.
Díky promyšlenému konceptu a v praxi odzkoušenému designu v kombinaci s výběrem kvalitních komponent je hotel stack platforma funkční řešení s přidanou hodnotou.
Modulární koncept, když chcete více nebo i méně, začít se dá i s minimalistickým hotel stackem, který bude s Vámi růst dle Vašich potřeb, chcete něco více docházkový systém, zabezpečovací ústřednu/alarm, definujte sami podobu svého hotelu.
Podpora → poskytuje SLA servisní smlouvu na celý stack na vybrané komponenty záruka 36 až 60 měsíců,poskytuje konfigurace a přizpůsobení, aktivní monitoring a reporting stavu stacku, dále vývoj řešení a aplikací na zakáznku v rámci hotel stacku včetně mobilních aplikací a napojení a třetí strany.
Zamilujte se ! Hotelové IT prostředí jako nikdy dosud...to je HOTEL STACK!
Technické konzultace, implementace, nacenění řešení. Kontaktní e-mail: podpora@mojeservery.cz Kontaktní telefon: +420 725 714 669
Hotel stack pro každého, nezáleží na provozu, pokryjeme stejně dobře potřeby škol, městských úřadů, knihoven, výrobních hal, skladů, malých i středních firem, nebojte se zeptat.
Linux mini-howto? Krátce o nástrojích ze života sysadmina.
Info: Následující krátký jednoduchý text vznikl na základě praktické zkušenosti dotazů a z workshopů, je cílen na mladší generaci síťařů/adminů pro objasnění, že i za tak jednoduchým nástrojem traceroute není žádná magie, není cílem nikoho urazit, pouze osvěta. Děkuji.
Nástroj traceroute umožňuje základní analýzu počítačové sítě formou textového výpisu směrovačů (uzlů) na cestě paketu od zdroje v cíli, jde tedy o velmi efektivní nástroj pro rychlé zobrazení aktuálních cesty (routování) v sítí, standardně je tento nástroj obsažen ve většině Linux/Unix systémech, ve světě Windows má svoji implementaci v podobě nástroje tracert. Pokračování textu Linux mini-howto: Diagnostický nástroj Traceroute
API, API, API (Application Programming Interface) je takové zaklínadlo dnešní doby, pokud služba/aplikace nedisponuje rozhraním pro komunikaci je vyřízená, nebrat doslovně, pojem API aby zde byl mnohem dříve než z něho web stihl udělat buzzword, konec konců už i DOS měl své API v podobě přerušení int 21h, služby BIOSu jsou API, systémová volání v moderních systémech nejsou nic jiného než opět API.
REST představuje jeden z konceptů (architektur) je vytvořit rozhraní, je postavená nad volání metod protokolem HTTP, datově orientované a masivně používané, oblíbené.
Malý pomocník, taky pomocník ...
ARC je aplikaci běžící uvnitř prohlížeče Chrome a dovoluje pohodlné odzkoušení API rozhraní, dříve jsme měli postup otestovat funkčnost a chování API pomocí jednoduchého řádkového klienta curl (a je stále dobré to umět, rozumět, lze to scriptovat a průběžně tak testovat) ještě předtím než zavoláte composer, požádáte ho o Guzzle a začnete “čarovat”.
“Absolutní výcuc” vyšel před lety na serveru Codingpedia.org.
http://www.codingpedia.org/ama/how-to-test-a-rest-api-from-command-line-with-curl/
Proč dát ARC šanci ?
Užívejte moudře, děkujeme za pozornost.
MOJEservery.cz
Miniexkurze, unikátní budova v ČR postavena přímo pro potřeby rozhlasu, živé vysílání s Vladimírem Šťovíčkem, prohlídka nahrávacího studia, děkujeme.
Český rozhlas Plzeň → http://www.rozhlas.cz/plzen/portal/
Živé vysílání→ http://prehravac.rozhlas.cz/plzen
Kamera ve studiu → http://www.rozhlas.cz/plzen/studio/
Linux mini-howto? Krátce o nástrojích ze života sysadmina.
V předchozím Linux-mini howto (Je tunelování TCP skrz TCP dobrý nápad ?) jsme na konci článku zmínili formou odkazů informace k této problematice i přes tento fakt a existenci Google přišlo pár dotazů jak na to, pojďme to v rychlosti proběhnout.
Diagnostika sítí je komplexní, rozsáhlá a složitá disciplína plná záludností, složitých software nástrojů a sofistikovaných drahých měřících přístrojů, přesto se hodí umět si vyrobit kontrolovaně svůj vlastní problém na stole (nemluvíme teď o “muchlání” a kroucení kabelů či nucení kolegů na chodbě běhat skrze bezdrátový spoj 
) a to zcela zdarma díky Linux jádru.
Zpoždění (latency)
https://cs.wikipedia.org/wiki/Latence#V_informatice
Ztrátovost paketů (packet loss)
https://cs.wikipedia.org/wiki/Ztráta_paketů
Linux jádro má již od verze 2.6 (dobře, vlastně od 2.4.37) implementovanou funkcionalitu pro network emulaci (netem), pokud máte kernel 2.6 a novější, zakompilovanou podporu Network emulatoru do jádra či jako modul a k tomu nainstalovaný obslužný nástroj tc (traffic control) z balíku iproute2 máte vše potřebné.
Networking -->
Networking Options -->
QoS and/or fair queuing -->
Network emulator
CONFIG_NET_SCH_NETEM=m
Popišme si alespoň základní koncept síťování v Linux, jednoduchá ilustrace nám dobře pomůže k pochopení, na jedné straně máme aplikace komunikující prostřednictvím systémových volání jádra (syscall) s IP stackem, chtějí komunikovat s hostem a.b.c.d, navazovat spojení, posílat data a o moc více se nestarat.
IP stack předává pakety do qdisc (Queueing discipline), což není nic jiného než scheduler (plánovač, kód v jádře systému) fronty, který rozhoduje o tom v jakém pořadí zpracovat pakety, každé výstupní rozhraní má alespoň jeden qdisc (scheduler, frontu), po průchodu frontou přes ovladač síťové karty putují data ven.
Výchozí fronta v Linuxu je většinou FIFO (First-in, First-Out).
root@netem-machine:~# tc -s qdisc qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap Sent 14757932 bytes 163954 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 root@netem-machine:~# tc qdisc show qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap
Výpisem pomocí nástroje tc jsme si ověřili aktuálně nastavený qdisc na zařízení eth0 (ethernet), je patrné, že máme nastavenou frontu typu pfifo (packet FIFO) z následující obrázku je vidět, že pfifo interně implementuje i jednoduchý priority mapping a obsahuje uvnitř tři různé fronty pro přednostní zpracování.
Pokud je fronta plná (linka je zatížená) a nemůže být přijmut další paket ke zpracování, dojde k jeho zahození, frontu lze pro tento účel zvětšit, následkem je většinou zvýšení latence, ale můžeme pozorovat i lepší využití linky.
Pro doplnění představ, v Linux jádře je dnes přes 20 různých schedulerů paketů (red, qfq, prio, mq, cbq, htb, sfq ,…) a nic Vám nebrání napsat si svůj vlastní unikátní pro Vaše potřeby. (http://lxr.free-electrons.com/source/net/sched/ )
Netem, skrze dlouhou okliku a vysvětlení qdisc se vraťme zpět k našemu emulátoru, z předchozích informací je zřejmé, že netem je implementován jako další plánovač paketů se schopností přidávat ke zpracování latence včetně náhodné distribuce, generovat ztrátovost, duplikovat i měnit pořadí paketů(reordering).
Použití je opravdu triviální, ukážeme si, nahrajeme modul netem do jádra, nastavíme na rozhraní eth0 qdisc netem, nastavíme parametry zpoždění, náhodného rozptylu, ztrátovosti a otestujeme.
root@netem-machine:~# modprobe sch_netem root@netem-machine:~# tc qdisc show qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap root@netem-machine:~# root@netem-machine:~# tc qdisc add dev eth0 root netem root@netem-machine:~# tc qdisc show qdisc netem 8004: dev eth0 root refcnt 2 limit 1000
Zpoždění 200ms , host 10.0.200.1 je součástí directly connected sítě, okamžitě lze vidět nárůst latence zde pomocí ping nástroje.
root@netem-machine:~# tc qdisc change dev eth0 root netem delay 200ms root@test-machine:~$ ping 10.0.200.1 PING 10.0.200.1 (10.0.200.1) 56(84) bytes of data. 64 bytes from 10.0.200.1: icmp_seq=1 ttl=64 time=0.295 ms 64 bytes from 10.0.200.1: icmp_seq=2 ttl=64 time=0.268 ms 64 bytes from 10.0.200.1: icmp_seq=9 ttl=64 time=0.230 ms 64 bytes from 10.0.200.1: icmp_seq=10 ttl=64 time=200 ms 64 bytes from 10.0.200.1: icmp_seq=11 ttl=64 time=200 ms 64 bytes from 10.0.200.1: icmp_seq=12 ttl=64 time=200 ms
Zpoždění 500ms ± 100ms, je vidět zpoždění ± s velkým rozptylem (ne realtime jádro s tím asi dost bojuje).
root@test-machine:~# tc qdisc change dev eth0 root netem delay 500ms 100ms root@test-machine:~$ ping 10.0.200.1 PING 10.0.200.1 (10.0.200.1) 56(84) bytes of data. 64 bytes from 10.0.200.1: icmp_seq=24 ttl=64 time=0.242 ms 64 bytes from 10.0.200.1: icmp_seq=25 ttl=64 time=0.272 ms --- aplikace netem --- root@test-machine:~$ ping 10.0.200.1 PING 10.0.200.1 (10.0.200.1) 56(84) bytes of data. 64 bytes from 10.0.200.1: icmp_seq=1 ttl=64 time=453 ms 64 bytes from 10.0.200.1: icmp_seq=2 ttl=64 time=479 ms 64 bytes from 10.0.200.1: icmp_seq=3 ttl=64 time=502 ms 64 bytes from 10.0.200.1: icmp_seq=4 ttl=64 time=491 ms 64 bytes from 10.0.200.1: icmp_seq=5 ttl=64 time=553 ms 64 bytes from 10.0.200.1: icmp_seq=6 ttl=64 time=532 ms 64 bytes from 10.0.200.1: icmp_seq=7 ttl=64 time=534 ms 64 bytes from 10.0.200.1: icmp_seq=8 ttl=64 time=490 ms 64 bytes from 10.0.200.1: icmp_seq=9 ttl=64 time=450 ms
Ztrátovost 10% (10% paketů bude náhodně zahazováno) + latence 100ms, náhodu lze ještě ovlivňovat korelací kdy je závislá na předchozím výsledku v %, je to trochu chaotické, ale vlastně méně chaotické, protože zmenšujeme náhodnost generátoru).
root@test-machine:~# tc qdisc change dev eth0 root netem delay 100ms loss 10% root@test-machine:~$ ping -q -c 10 10.0.200.1 PING 10.0.200.1 (10.0.200.1) 56(84) bytes of data. --- 10.0.200.1 ping statistics --- 10 packets transmitted, 9 received, 10% packet loss, time 9026ms rtt min/avg/max/mdev = 100.222/100.298/100.371/0.163 ms root@test-machine:~$ ping -q -c 10 10.0.200.1 PING 10.0.200.1 (10.0.200.1) 56(84) bytes of data. --- 10.0.200.1 ping statistics --- 10 packets transmitted, 6 received, 40% packet loss, time 9013ms rtt min/avg/max/mdev = 100.197/100.239/100.295/0.185 ms
Základní představu o konceptu netem a jeho využití jsme snad představili, studujte dokumentaci, další pěknou věcí, která stojí za vyzkoušení je poškozování paketů (netestovali jsme bohužel), není špatné si pro přehled projít i zdrojový kód netem, pěkné je nasazení netem i na příchozí provoz pomocí modulu IFB (pouze otočí in přes pseudo device na out a na něm udělat netem) v ukázkách dokumentace nejdete jak netem protáhnout i jen specifický traffic přes tc filter, omezit rychlost apod … prostě studujte.
V našem případě při testování a hledání problémů s TCP over TCP jsem si postavili script který měnil hodnoty zpoždení a ztrátovosti od malých až po extrémní, tak aby jsme donutili TCP prodlužovat adaptivní timeout a sledovat pomocí tcpdump/wireshark co se děje uvnitř spojení.
Děkuji za pozornost.
František Havel, MOJEservery.cz
Zdroje:
http://man7.org/linux/man-pages/man8/tc-netem.8.html
http://lxr.free-electrons.com/source/net/sched/sch_netem.c
http://www.linuxfoundation.org/collaborate/workgroups/networking/netem
Základní úvod do uspořádání hierarchie souborového systému v operačních systémech Linux/Unix.
—
Další díl našeho mini-seriálu je na světě, pohodlně se usaďte, uvařte škopek kafe, odpoutejte se, kuřte a startujem. :-).
Líbilo se? Dejte like, komentář nebo odběr kanálu a sdílejte.
Děkujeme za Vaši podporu. MOJEservery.cz
