abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 15:00 | Pozvánky

Sdružení CESNET ve spolupráci se společností Trend Micro spustilo registraci do hackerské soutěže The Catch 2018. Soutěž proběhne stejně jako vloni v rámci Měsíce kybernetické bezpečnosti.

Ladislav Hagara | Komentářů: 0
dnes 10:33 | Nová verze

Po pěti měsících vývoje od vydání verze 1.15 byla vydána (YouTube) nová major verze 2.0 (2.0.1309.29) webového prohlížeče Vivaldi (Wikipedie). Přináší především synchronizaci uživatelských dat. Novinkou jsou také plovoucí panely. Dále je vylepšena přizpůsobitelnost nebo i práce s listy. Nejnovější Vivaldi je postaveno na Chromiu 69.0.3497.102.

Ladislav Hagara | Komentářů: 0
včera 23:33 | Nová verze

Opera 56, verze 56.0.3051.31, byla prohlášena za stabilní. Z novinek vývojáři upozorňují například na vylepšenou funkci vyskakovacích videí - v plovoucím rámci lze nově nastavovat hlasitost. Podrobný přehled změn v Changelogu. Přehled novinek pro vývojáře na blogu Dev.Opera. Opera 56 je postavena na Chromiu 69.

Ladislav Hagara | Komentářů: 9
včera 21:55 | Nová verze

Společnost Oracle oficiálně oznámila vydání Java SE 11 (JDK 11). Jedná se o verzi s prodlouženou podporou (LTS). Nových vlastností (JEP - JDK Enhancement Proposal) je 17. Nové verze Java SE vychází každých 6 měsíců.

Ladislav Hagara | Komentářů: 0
včera 18:44 | Nová verze

Byla vydána (en) betaverze Fedory 29. Jedná se o poslední zastávku před finálním vydáním a vzhledem k tomu, že byla zrušena alfa, tak také o první. K dispozici je v oficiálních edicích Workstation, Server a Atomic a také v podobě spinů, labů a verze pro ARM. Vydání Fedory 29 je plánováno na 30. října.

Ladislav Hagara | Komentářů: 0
včera 11:44 | Komunita

Aktuální verzi knihy Everything curl věnované řádkovému nástroji a knihovně pro přenos dat po různých protokolech curl lze koupit v papírové formě. Kniha je volně k dispozici na stránkách curlu nebo ke stažení ve formátech PDF, MOBI a EPUB. Ve spolupráci s BountyGraph byl spuštěn bug bounty program aneb za nalezení kritické bezpečnostní chyby v curlu lze vydělat aktuálně až 33 268 dolarů. Částkou 32 768 dolarů přispěl Dropbox. Curl již umí TLS

… více »
Ladislav Hagara | Komentářů: 0
včera 11:33 | Zajímavý projekt

Cloudflare spustil experimentální provoz ESNI - šifrovaného SNI (Server Name Indication), které umožňuje chránit soukromí uživatelů přistupujících k webům přes HTTPS. ESNI je podporováno zatím v testovací verzi Firefoxu. Při současném použití šifrovaného DNS (DNS-over-TLS či DNS-over-HTTPS) tak ISP či státy již nebudou mít žádnou přesnou možnost, jak kontrolovat či blokovat stránky, ke kterým uživatelé přistupují. Více viz také IETF draft.

xm | Komentářů: 0
24.9. 21:33 | Nová verze

Byla vydána nová major verze 1.8.0 open source systému pro filtrování nevyžádané pošty Rspamd (GitHub, ChangeLog). Z novinek lze zmínit nový framework selectors, optimalizaci modulu ClickHouse nebo vylepšení webového rozhraní.

Ladislav Hagara | Komentářů: 2
24.9. 18:44 | Bezpečnostní upozornění

Sabri Haddouche vytvořil stránku Browser Reaper, na které demonstruje zranitelnosti současných verzí webových prohlížečů Chrome, Safari i Firefox. Zveřejněné skripty dokážou zahltit nejen webové prohlížeče, ale v závislosti na nastavení, také celé operační systémy.

Ladislav Hagara | Komentářů: 13
23.9. 19:22 | Nová verze

Byla vydána verze 11.3 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab (Wikipedie). Představení nových vlastností i s náhledy v příspěvku na blogu.

Ladislav Hagara | Komentářů: 0
Na optické médium (CD, DVD, BD aj.) jsem naposledy vypaloval(a) data před méně než
 (14%)
 (14%)
 (20%)
 (24%)
 (24%)
 (4%)
 (0%)
Celkem 419 hlasů
 Komentářů: 35, poslední včera 09:16
Rozcestník

Stavíme poštovní server – 17 (optimalizace výkonu)

19. 4. 2010 | Lukáš Jelínek | Sítě | 10692×

Pokud není poštovní server příliš zatížen, není obvykle potřeba se nějak významně zabývat tím, jak je optimalizován z hlediska výkonu. Pokud ale průtok zpráv a uživatelských přístupů stoupá, nabývá optimalizace serveru na významu.

Obsah

Silnější železo, nebo optimalizace?

link

S rostoucí zátěží serveru (nejen poštovního) se stává aktuální otázka, jak se s touto zátěží vypořádat. Nabízejí se v zásadě tři možná řešení:

  • posílení hardwaru
  • změna architektury
  • optimalizace konfigurace

Nejjednodušší řešení zátěže je posílení hardwaru, lidově řečeno „silnější železo“. Může to zahrnovat výměnu či přidání procesoru, rozšíření operační paměti, nasazení rychlejších disků či změnu konfigurace pole RAID, zvýšení rychlosti síťového připojení atd. Výhoda je, že jednoduše posílí ten prostředek, kterého se nedostává. Stojí to však určité peníze a mnohdy to nelze provést bez výměny celého serveru (například proto, že základní deska toho současného více procesorů či větší paměť neumožňuje přidat). Navíc pokud je velká zátěž jen přechodný jev (typicky při útoku), bylo by navyšování hrubé síly zbytečné.

Další možnost je změna architektury – a to jak ve smyslu serveru jako celku, tak i poštovního řešení. Server jako celek lze virtualizovat a nastavovat mu prostředky podle potřeby (takže stačí mít velmi výkonný fyzický stroj a provozovat na něm více serverů virtuálních; lze tím ušetřit za hardware). Změna architektury poštovního řešení může znamenat například oddělení rolí serveru (např. doručování a relaying), přenesení některých služeb na samostatné stroje (např. greylisting, databáze, antivirová kontrola), použití samostatného úložiště atd. Změny architektury jsou dobrá volba pro dlouhodobý horizont, ovšem pokud je potřeba najít řešení nadměrné zátěže ihned, může to být velmi nákladné a něco se může zbytečně uspěchat.

Poslední možnost je optimalizace stávajícího serveru, jeho konfigurace. Na přímých nákladech to nebude stát ani korunu, veškeré změny se odehrají jen v rámci konfigurace. Vždy je to samozřejmě něco za něco. Vylepšení některých vlastností může mít za následek zhoršení jiných.

Kdo očekává, že budou následující odstavce prošpikované kouzelnými hodnotami, které stačí někam zadat, a vše bude najednou skvělé, bude asi zklamán. Takhle jednoduché to není, ostatně kdyby bylo, vyřešili by to tvůrci programu sami a nebylo by potřeba nic konfigurovat. Další text bude tedy hodně v obecné rovině, konkrétní řešení je třeba vždy tvořit pro danou reálnou situaci.

Adaptivní změna chování

link

Verze 2.5 programu Postfix přináší jedno zásadní vylepšení, týkající se funkce při extrémní zátěži. Zavádí totiž stress-adaptive behavior čili „stresově adaptivní chování“. Funguje to tak, že pokud se server dostane do stavu přetížení (nelze obsloužit dalšího klienta), řídící proces master restartuje službu (typicky smtpd) v režimu pro vysokou zátěž. Aktuálně otevřené relace jsou obslouženy ještě v původním režimu.

Smyslem existence režimu je řešit krátkodobé stavy extrémní zátěže (masivní připojování ze spammerských botnetů, různé DoS a DDoS útoky atd.), nikoli trvalý nadměrný provoz.

Režim pro vysokou zátěž využívá samostatnou konfiguraci důležitých parametrů, které mají vliv na to, jak proběhne obsloužení připojeného klienta. Využívají se k tomu podmínkové konstrukty v konfiguračním souboru. Bude proto nejlepší podívat se nejprve na ně, protože je lze využít obecněji, nikoli jen v tomto případě.

Podmínkové konstrukty v main.cf

link

Veškeré dosud uváděné příklady konfigurace (v souboru main.cf) ukazovaly jen obyčejné přiřazování hodnot, ať již přímo, nebo přes nějaký datový zdroj. Nicméně již od verze 2.2 umožňuje Postfix vázat na to, zda je určitý parametr neprázdný nebo naopak prázdný. Obecný formát vypadá takto:

${name?value}
${name:value}

Připomíná to ternární operátor známý například z jazyka C, nicméně v tomto případě je rozdělen na dvě části. V prvním případě se uvedená hodnota použije, je-li obsah parametru neprázdný, ve druhém případě pro opačnou situaci, tedy prázdný parametr. Tady je konkrétní příklad:

relay_clientcerts = ${relayhost?hash:/etc/postfix/relay_clientcerts}

Tento zápis říká, že pokud je parametr relayhost neprázdný, nastaví se relay_clientcerts na uvedenou hodnotu (jinak bude prázdný). Oba konstrukty lze kombinovat a dosáhnout situace, jako kdyby se jednalo o ternární operátor:

smtpd_delay_reject = ${smtpd_client_restrictions?no}${smtpd_client_restrictions:yes}

V případě neprázdného parametru smtpd_client_restrictions se pro smtpd_delay_reject použije hodnota no, v opačném případě hodnota yes. Velmi se to bude hodit pro režim vysoké zátěže, jak se vzápětí ukáže.

Parametry pro režim vysoké zátěže

link

Při extrémní zátěži lze serveru odlehčit tím, že se některé parametry změní tak, aby se server se zátěží lépe vyrovnal. Týká se to hlavně následujících skupin parametrů:

  • časové limity (timeouty)
  • tolerance vůči chybám
  • limity na frekvenci a počet zpráv a příjemců
  • využívání vzdálených blacklistů/whitelistů

Veškeré změny se však týkají jen služeb, které jsou veřejně přístupné (typicky tedy smtpd, případně včetně submission, pokud se používá). U ostatních služeb se režim vysoké zátěže nepoužívá.

Následující fragment souboru main.cf ukazuje možnou úpravu parametrů pro účely režimu vysoké zátěže:

smtpd_timeout = ${stress?10}${stress:300}s

smtpd_soft_error_limit = ${stress?1}${stress:10}
smtpd_hard_error_limit = ${stress?1}${stress:20}
smtpd_junk_command_limit = ${stress?1}${stress:100}

smtpd_client_connection_rate_limit = ${stress?10}${stress:0}
smtpd_client_message_rate_limit = ${stress?30}${stress:0}
smtpd_client_recipient_rate_limit = ${stress?300}${stress:0}
smtpd_recipient_limit = ${stress?100}${stress:0}
smtpd_recipient_overshoot_limit = ${stress?10}${stress:1000}

Takováto konfigurace znamená, že za běžných podmínek (server není příliš zatížen) se nebudou uplatňovat přísná omezení – ta nastoupí až v situaci, kdy dojde k přetížení serveru a služba smtpd bude nastartována v režimu vysoké zátěže (stress). Pak se například timeout zkrátí na 10 sekund, limit chyb a „prázdných“ příkazů klesne na 1 atd.

U Postfixu od verze 2.6 není potřeba některé z těchto parametrů nastavovat (viz manuál), protože výchozí hodnoty již s režimem vysoké zátěže počítají. Verze 2.5 však tato nastavení potřebuje.

Nastavování přísných omezení může být porušením RFC 2821 a hlavně může působit problémy některým legitimním klientům. Je proto potřeba vždy hledat rovnováhu mezi nutností aplikovat omezení a potřebou chránit před těmito omezeními legitimní provoz. Často je lepší postupovat raději konzervativně a přetěžování serveru (například ze strany botnetů) řešit i jinými prostředky.

       

Hodnocení: 100 %

        špatnédobré        

Nástroje: Tisk bez diskuse

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

19.4.2010 10:54 ch-in-A
Rozbalit Rozbalit vše vyborny, clanek!
vyborny, clanek/serial! diky
Josef Kufner avatar 19.4.2010 15:52 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: vyborny, clanek!
+1

Chtělo by to ještě pár dílů o nějakých pěkných specialitkách. Třeba jak na virtuální imap složky v dovecotu a podobné věci (trošu jsem je oťukával, ale moc to nefungovalo).
Hello world ! Segmentation fault (core dumped)
ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.