W ostatnich latach coraz popularniejsze stają się serwisy zabezpieczające przed atakami DDoS. Jedną z takich firm jest Cloudflare, która może przejąć na siebie przychodzący ruch HTTP, odczyścić go i przekazać do docelowej lokalizacji.
Aby udostępnić w ten sposób usługę HTTPS, trzeba było dotąd przekazać zewnętrznemu podmiotowi klucze SSL. Dla wielu firm jest to rozwiązanie nieakceptowalne. Potrzeba jednak matką wynalazku i oto Cloudflare zaprezentował Keyless SSL™. W tym rozwiązaniu serwer pośredniczący zakańczający szyfrowane połączenie w czasie ustanawiania szyfrowanej sesji sięga bezpiecznym kanałem do dedykowanego serwera kluczy po stronie klienta. W ten sposób klucze pozostają nadal po stronie klienta, a Cloudflare realizuje w jego imieniu szyfrowane połączenia i wykonuje inspekcję ruchu. Rozwiązanie może przydać się również podmiotom, które nie korzystają z tego typu ochrony, a chcą uniknąć umieszczania kluczy na load balancerach w datacenter. Więcej informacji w artykule "The Nitty Gritty Technical Details".
sobota, 4 października 2014
poniedziałek, 19 marca 2012
Co słychać w Linux 3.3 i NetBSD 6.0?
Ależ te numerki wersji Linuksa galopują! ;) Przejrzałem właśnie z ciekawości listę zmian w Linux 3.3, zwracam uwagę na sieciowe usprawnienia:
Zbliża się także wydanie NetBSD 6.0. Na liście zmian m.in.:
Tempo rozwoju tego systemu zdecydowanie nie powala...
Podobnie jak w korpo, tutaj również mamy zderzenie modeli "szybko, dużo, chaotycznie" z "powoli, rzetelnie i schludnie". Worse is better. ;-)
- teaming, czyli lepszy bonding
- Open vSwitch, wirtualny przełącznik Ethernet, który będzie szalenie pomocny m.in. dla OpenFlow
Zbliża się także wydanie NetBSD 6.0. Na liście zmian m.in.:
Tempo rozwoju tego systemu zdecydowanie nie powala...
Podobnie jak w korpo, tutaj również mamy zderzenie modeli "szybko, dużo, chaotycznie" z "powoli, rzetelnie i schludnie". Worse is better. ;-)
sobota, 25 lutego 2012
Twarde fluszowanie buforów
Dawno nie było "twardego" wpisu...
Gdy tworzymy aplikację i kod zapisujący do pliku, zwykle traktujemy operację zapisu jako wykonaną gdy sterowanie w kodzie przejdzie do kolejnych instrukcji. Zazwyczaj to fałszywe poczucie bezpieczeństwa w niczym nie przeszkadza. Do czasu, gdy pojawi się sytuacja awaryjna: aplikacja, system operacyjny, dyski lub zasilanie padną.
Odkrywamy jednak operację typu (f)flush() i czujemy się lepiej, bufory mamy opróżnione. Bardzo miło, ale nasza sytuacja w razie awarii systemu nie jest wiele lepsza. Jedyne co osiągnęliśmy, to wypchnięcie danych z jednych buforów do drugich (OS). Dane nadal nie są utrwalone. Jeśli oprogramowanie zapisuje krytyczne dane, realizuje jakąś transakcję, to kiepsko to wygląda.
Aby je utrwalić na nośnikach, musimy sięgnąć po fsync(). Bardzo ładnie jest to wyjaśnione tutaj.
Oczywiście, one nadal nie muszą być utrwalone. Jest jeszcze sterownik systemu plików, sterownik urządzenia blokowego, bufor w macierzy/kontrolerze dysków i w samym dysku! Ale jeśli sterowniki, kontroler dysków i firmware dysku są OK, no to w końcu czujemy się lepiej. Problem w tym, że nie zawsze są OK.
Poza tym, nawet jeśli są OK, awaria dysku/zasilania może przyjść w trakcie zapisywania danych na dysk i zapiszą się tylko częściowo i nie w tej kolejności, w której były zlecone. Implikacje mogą być bardzo daleko idące i dotyczą głównie implementacji: systemów plików, baz danych, systemów transakcyjnych, systemów kolejkowych czy nawet serwera pocztowego. Na pewno wszędzie, gdzie liczy się ACID.
Niektóre systemy udostępniają dodatkowe możliwość wpłynięcia na proces utrwalania, np. Mac OS X udostępnia w fnctl() opcję F_FULLFSYNC. Również Windows udostępnia funkcję FlushFileBuffers() do czyszczenia (całego) cache dysku oraz tryb otwarcia pliku FILE_FLAG_WRITE_THROUGH, których opis sugeruje, że załatwiają sprawę (głowy nie dam, ale wg tego porównania wypada nieźle).
Istnieją narzędzia, które świadomie korzystają z tego dobrodziejstwa, np.:
Istnieją ponadto techniki radzenia sobie z częściowym utrwaleniem danych na podsystemie dyskowym w aplikacjach, które przepisują daną "w miejscu". Dla przykładu Websphere MQ zapisuje dziennik operacji (journal) w stronach i może się zdarzyć, że strona nie jest pełna. Wówczas zapisywana jest część strony, a reszta zostaje dopisana później. Ta druga operacja potencjalnie może skutkować utratą danych tego pierwszego zapisu. Aby to obejść, Websphere MQ domyślnie stosuje dla loga operacji metodę zapisu (LogWriteIntegrity) TripleWrite. Powoduje to dla niepełnych stron loga zapis pierwszej "połówki", na kolejnej stronie commit drugiej "połówki", a następnie (trzeci zapis) commit obu połówek razem do tej pierwszej strony.
To na ostateczne popsucie humoru:
Gdy tworzymy aplikację i kod zapisujący do pliku, zwykle traktujemy operację zapisu jako wykonaną gdy sterowanie w kodzie przejdzie do kolejnych instrukcji. Zazwyczaj to fałszywe poczucie bezpieczeństwa w niczym nie przeszkadza. Do czasu, gdy pojawi się sytuacja awaryjna: aplikacja, system operacyjny, dyski lub zasilanie padną.
Odkrywamy jednak operację typu (f)flush() i czujemy się lepiej, bufory mamy opróżnione. Bardzo miło, ale nasza sytuacja w razie awarii systemu nie jest wiele lepsza. Jedyne co osiągnęliśmy, to wypchnięcie danych z jednych buforów do drugich (OS). Dane nadal nie są utrwalone. Jeśli oprogramowanie zapisuje krytyczne dane, realizuje jakąś transakcję, to kiepsko to wygląda.
Aby je utrwalić na nośnikach, musimy sięgnąć po fsync(). Bardzo ładnie jest to wyjaśnione tutaj.
Oczywiście, one nadal nie muszą być utrwalone. Jest jeszcze sterownik systemu plików, sterownik urządzenia blokowego, bufor w macierzy/kontrolerze dysków i w samym dysku! Ale jeśli sterowniki, kontroler dysków i firmware dysku są OK, no to w końcu czujemy się lepiej. Problem w tym, że nie zawsze są OK.
Poza tym, nawet jeśli są OK, awaria dysku/zasilania może przyjść w trakcie zapisywania danych na dysk i zapiszą się tylko częściowo i nie w tej kolejności, w której były zlecone. Implikacje mogą być bardzo daleko idące i dotyczą głównie implementacji: systemów plików, baz danych, systemów transakcyjnych, systemów kolejkowych czy nawet serwera pocztowego. Na pewno wszędzie, gdzie liczy się ACID.
Niektóre systemy udostępniają dodatkowe możliwość wpłynięcia na proces utrwalania, np. Mac OS X udostępnia w fnctl() opcję F_FULLFSYNC. Również Windows udostępnia funkcję FlushFileBuffers() do czyszczenia (całego) cache dysku oraz tryb otwarcia pliku FILE_FLAG_WRITE_THROUGH, których opis sugeruje, że załatwiają sprawę (głowy nie dam, ale wg tego porównania wypada nieźle).
Istnieją narzędzia, które świadomie korzystają z tego dobrodziejstwa, np.:
- SQLite (trop)
- patch do Erlanga (uwzględnione) przysłany przez CouchDB
- ActiveMQ (kod)
- H2 DB udostępnia, ale domyślnie świadomie rezygnuje (analiza)
Istnieją ponadto techniki radzenia sobie z częściowym utrwaleniem danych na podsystemie dyskowym w aplikacjach, które przepisują daną "w miejscu". Dla przykładu Websphere MQ zapisuje dziennik operacji (journal) w stronach i może się zdarzyć, że strona nie jest pełna. Wówczas zapisywana jest część strony, a reszta zostaje dopisana później. Ta druga operacja potencjalnie może skutkować utratą danych tego pierwszego zapisu. Aby to obejść, Websphere MQ domyślnie stosuje dla loga operacji metodę zapisu (LogWriteIntegrity) TripleWrite. Powoduje to dla niepełnych stron loga zapis pierwszej "połówki", na kolejnej stronie commit drugiej "połówki", a następnie (trzeci zapis) commit obu połówek razem do tej pierwszej strony.
To na ostateczne popsucie humoru:
- znacie programistów krytycznych aplikacji biznesowych ;) w Java, którzy świadomie robią coś więcej niż flush() by utrwalić dane?
- znacie kogoś, kto ma transakcyjną bazę danych SQL lub serwer SMTP na "oszukujących" dyskach SATA? (co lepsze, te low-endowe dyski mają duże 16-64MB cache)
- co się stanie z e-mailem, gdy serwer SMTP potwierdzi jego przyjęcie i nie zrobi fsync() na pliku w spoolu, po czym padnie zasilanie?
- znacie administratorów Linux, którzy świadomie wyłączają write cache na dyskach? (czasami robią to za nich same kontrolery macierzowe)
- zastanawialiście się co czeka system plików w wirtualnej maszynie po padzie hosta, zwłaszcza gdy ów filesystem gościa jest plikiem na systemie hosta? (hint)
- czy Wasz system plików księguje (journalling) dane, czy tylko metadane?
- ile lat temu pojawiło się wsparcie dla wiarygodnego utrwalania danych w Twoich krytycznych aplikacjach i systemach?
środa, 22 lutego 2012
Pracownik IT ma generować zyski
Dziś będzie brutalnie. Dlaczego pracodawca miałby Tobie dużo płacić? "Bo to IT"? Dobre żarty. "Bo znam się na X"? Ha ha ha! Otóż pracodawca może dużo zapłacić, jeśli czuje, że zarobi na Tobie jeszcze więcej. :-)
Jak można zarobić na pracowniku IT?
Płyną z tego pewne oczywiste wnioski dotyczące zarobkowania w IT:
Jak można zarobić na pracowniku IT?
- Można go komuś odsprzedać z marżą. Popularny motyw w różnych informatycznych stonkach. Firma ma dojście do koryta, a studenci lubią pracę po nocach bo chcą zarobić na piwo.
- Można też wykonać jego rękami zmiany, które przyniosą realne oszczędności w firmie. I taki jest sens istnienia IT w firmie: obniżać koszty poprzez automatyzację, umożliwiać poprzez informatyzację.
Płyną z tego pewne oczywiste wnioski dotyczące zarobkowania w IT:
- nie idziesz do stonki po kasę, a co najwyżej po know-how
- jeśli IT w firmie jest tylko kosztem, to mogą mieć kiepski budżet na płace
- jeśli sprzedajesz się do jakiejś firmy, nie skupiasz się tylko na tym co umiesz, ale także na tym, ile to pozwoliło poprzednim firmom zaoszczędzić/zarobić pieniędzy
- im bardziej niszowa i gówniana technologia, tym lepiej dla portfela (choć gorzej dla satysfakcji)
- warto być blisko koryta (prawidło uniwersalne)
- dobrze jest wynajmować tanich wyrobników w Polsce B, sprzedawać ich za dobrą stawkę w Polsce A i odcinać kupony od podjętego ryzyka
poniedziałek, 6 lutego 2012
IPv4 nie chcą się skończyć
Polityka "utrudnień" w uzyskaniu alokacji IPv4 i celowa fragmentacja ostatnich zakresów przynosi skutki. RIPE informuje w "IPv4 Allocation Statistics for 2011", że:
In 2011 we saw a decrease in the total number of IPv4 addresses allocated, but an increase in the number of the allocations given out by the RIPE NCC. IPv4 is certainly running out, but there is no great rush for the last addresses as feared.Wygląda na to, że IPv6 będzie się hartowało jeszcze bardzo długo. ;-)
Subskrybuj:
Posty (Atom)