Tomasz Wendlandt

W niedawno wydanym Kernelu 2.6.32 dodano ciekawy ficzer z punktu widzenia wirtualizacji – Kernel Samepage Merging, wcześniej znany jako Kernel Shared Memory. Specjalny daemon kernel, ksmd skanuje pamięć w poszukiwaniu takich samych stron, które można zastąpić pojedyńczym wpisem. Jak podaje http://kernelnewbies.org przyczynia się to do bardzo dużego obniżenia zużycia pamięci w środowiskach wirtualizowanych.

Modern operative systems already use memory sharing extensively, for example forked processes share initially with its parent all the memory, there are shared libraries, etc. Virtualization however can’t benefit easily from memory sharing. Even when all the VMs are running the same OS with the same kernel and libraries the host kernel can’t know that a lot of those pages are identical and can be shared. KSM allows to share those pages. The KSM kernel daemon, ksmd, periodically scans areas of user memory, looking for pages of identical content which can be replaced by a single write-protected page (which is automatically COW’ed if a process wants to update it). Not all the memory is scanned, the areas to look for candidates for merging are specified by userspace apps using madvise(2): madvise(addr, length, MADV_MERGEABLE).

The result is a dramatic decrease in memory usage in virtualization environments. In a virtualization server, Red Hat found that thanks to KSM, KVM can run as many as 52 Windows XP VMs with 1 GB of RAM each on a server with just 16 GB of RAM. Because KSM works transparently to userspace apps, it can be adopted very easily, and provides huge memory savings for free to current production systems. It was originally developed for use with KVM, but it can be also used with any other virtualization system – or even in non virtualization workloads, for example applications that for some reason have several processes using lots of memory that could be shared.

http://lwn.net/Articles/306704/
http://lwn.net/Articles/330589/

Krótkie wprowadzenie do stackowania switchy 3750. Na początek łączymy wszystkie switche na krzyż kablami CAB-STACK. Mamy do wyboru trzy długości: 1m, 3m i 50cm.

Sprawdzamy czy podłączone kable są widziane w IOSie:

Switch#sh switch stack-ports
  Switch #    Port 1       Port 2
  --------    ------       ------
    1           Ok           Ok
    2           Ok           Ok

I czy ring, który właśnie stworzyliśmy ma pełną prędkość czyli 32Gbps. Co oznacza, że w modelu C3750 24-portowym osiągniemy pełną prędkość jednocześnie na wszystkich portach. Jednak w C3750 48-portowym już nie. Prędkość ringu jest dzielona pomiędzy urządzenia w stacku. Ponadto każdy port ASIC ma połączenie do obu ringów.

Switch#sh switch stack-ring speed

Stack Ring Speed        : 32G
Stack Ring Configuration: Full
Stack Ring Protocol     : StackWisePlus

Powyżej widać, że protokół użyty w ringu to StackWise Plus dostępny w nowszych switchach 3750-E. Dla StackWise w wersji Plus jeżeli ramka ma src i dst na tym samym switchu wchodzącym w skład stacka to nie jest ona rozgłaszana na ringu, wówczas w ruchu bierze udział jedynie wewnętrzny fabric. Z kolei dla zwykłego StackWise, który jest dostępny na zwykłych przełącznikach 3750 każda ramka rozgłaszana jest na ringu. Ponadto dla ramek Unicast StackWise Plus używa Destination Stripping co powoduje usunięcie ramki z ringu w momencie, gdy dotrze ona do przełącznika, na którym jest odbiorca. Dzięki temu pozostaje więcej pasma na ruch między pozostałymi switchami. W zwykłym StackWise dostępny jest jedynie Source Stripping co powoduje, że ramka zawsze musi przejść przez cały ring.

W łatwy sposób możemy sprawdzić ile ramek zostało wysłanych przez ring.

Switch#sh switch stack-ring activity

Sw  Frames sent to stack ring (approximate)
------------------------------------------------
1           82425
2           53761

Total frames sent to stack ring : 136186

Note: these counts do not include frames sent to the ring
by certain output features, such as output SPAN and output
ACLs.

Można też zweryfikować który kabel stackujący jest podłączony do którego portu w sąsiednim switchu.

Switch#sh switch neighbors

  Switch #    Port 1       Port 2
  --------    ------       ------
      1         2            3
      2         3            1
      3         1            2

Trzeba pamietać, że przy dodawaniu nowego przełącznika do stacku urządzenie zrebootuje się, a jego konfiguracja zostanie nadpisana przez konfigurację obowiązującą w stacku. Można oczywiście dodać nowy przełącznik jako mastera, przez nadanie mu odpowiednio wysokiego priorytetu. Wówczas nowy master zostanie dołączony, a pozostałe switche w stacku zrebootują się z nową konfiguracją.

Switch#switch stack-member-number priority new-priority-value

I jeszcze jedna ważna sprawa. Przy budowaniu stacku warto ustawić stack-mac persistent timer na 0.

Switch#sh run | i stack
stack-mac persistent timer 0

Zapobiega to zmianie MAC adresu stacku, w przypadku pojawienia się nowego mastera, np. przez dodanie nowego switcha z wyższym prio niż obecny master lub uszkodzeniu obecnego mastera.

Na koniec przydatne linki: Creation and Management of Catalyst 3750 Switch Stacks, Cisco StackWise Technology White Paper.

“V9.4.8 HF1 has been pulled from the download site, and HF2 will be available next week. CR133528 will be included in HF2 to addresses a memory leak that is possible in v9.4.8 HF1.

To tell if your system is susceptible to the memory leak in v9.4.8 HF1, run this command periodically and see if the Alloc/Max data entries keep growing:

b memory | grep -i packet
(SUBSYSTEM                        Alloc     Max    Obj size)
packet                                65920   66048     128

If your system is susceptible to this memory leak, please run the HF1 uninstall, HotfixUninstall-BIGIP-9.4.8-379.3-HF1.im, which is still available on the download site.“

Przypadkiem trafiłem na plugin F5 do Wiresharka.

This package contains the source for a Wireshark 0.99.7 plugin to decode additional data encoded in a tcpdump capture from an F5 device.

http://devcentral.f5.com/wiki/default.aspx/AdvDesignConfig/F5WiresharkPlugin.html

Niestety pod Windowsem trzeba się trochę pomęczyć, żeby to zainstalować.

Filtrowanie prefixów w BGP bywa uciążliwe. Szczególnie w przypadku, gdy nie chcemy otrzymywać całej tablicy od naszego ISP i filtrować ją u siebie na wejściu, a jedynie otrzymywać prefixy które nas interesują. Trzeba wówczas dogadywać się z naszym ISP i prosić go o aktualizację filtrów po jego stronie. Po kilku takich prośbach możemy zostać zakwalifikowani przez naszego dostawcę do kategorii meczybuła;). Dlatego idealnym rozwiązaniem w takim przypadku jest użycie ORFów. Wystarczy, że na routerze ISP zostanie wprowadzone:

(config-router)# neighbor NASZE_IP capability orf prefix-list recive

A my po swojej stronie dodamy do konfiguracji:

(config-router)# neighbor IP_ISP capability orf prefix-list send
(config-router)# neighbor IP_ISP prefix-list DENY_PREFIXES in

Powiedzmy, że nie chcemy otrzymywać prefixu 1.1.1.0/24 i 2.1.1.0/24. Natomiast interesują nas wszystkie pozostałe.

(config)# ip prefix-list DENY_PREFIXES seq 5 deny 1.1.1.0/24
(config)# ip prefix-list DENY_PREFIXES seq 10 deny 2.1.1.0/24
(config)# ip prefix-list DENY_PREFIXES seq 15 permit 0.0.0.0/0 le 32

Trzeba tylko pamietać, że w trakcie konfiguracji ORF rezwie się sesja BGP z naszym ISP, ale od tego momentu wszystkie zmiany w filtrowanych prefiksach możemy robić już po stronie ISP. Daje to dużo większą elastyczność i wygodę w filtrowaniu tras.

Jeżeli chcemy zmodyfikować prefix-listy to po jej modyfikacji trzeba wykonać:

# clear ip bgp neighbor in [prefix-list]

Przy wykonywaniu tego polecenia dla ORFów trzeba podać właśnie taką składnie z in i prefix-list NAZWA

Ciekawe zestawienie największych graczy na rynku loadbalancerów.

Od paru(nastu) dni krąży po sieci exploit pozwalający na położenie Apache’a oraz Squid’a. Idea działania exploitu jest taka, że skrypcik perlowy nawiązuje normalne połączenie TCP a następnie wysyła kolejno częściowe request’y HTTP. Każde z takich częściowych wywołań rezerwuje zasoby serwera do wykonania odpowiedzi i czeka na resztę wywołania, które nie przychodzi. Skutki są łatwe do przewidzenia.

Jest kilka metod zabezpieczenia się przed tym atakiem. Okazuje się, że nie tylko F5tkowy ASM, ale również LTM z ustawionym profilem http dla danego VServera potrafi ochronić farmę Apache/Squid przed atakiem Slowloris’em. Po raz kolejny potwierdza się, że F5 LTM rządzi:).

UPDATE: https://support.f5.com/kb/en-us/solutions/public/10000/200/sol10260.html

Jestem na konferencji Velocity 2009. Całkiem ciekawa impreza poświęcona wydajności sajtów i ich architekturze. Na miejscu można posłuchać prelekcji takich ludzi jak Jeremy Zawodny (znany spec od MySQLa), Steve Souders (pracujący dla Google’a, autor m.in. wtyczki YSlow oraz książki “High Performance Web Sites”) czy Matt Mullenweg (założyciel projektu Wordpress). Do tego ludzie z czołowych firm IT: Facebook, Google, Twitter, Youtube, Yahoo, MySpace, Wikia, AOL czy Mozilla. Oczywiście jak to bywa przy takich imprezach nie może zabraknąć też nudziarzy czy ludzi opowiadających o rzeczach, o których już dawno się wie. Jednak po obejrzeniu większości prezentacji uważam, że warto było się tutaj pojawić i dostać parę newsów i rozwiązań z pierwszej ręki. Czasami dobrze jest sięgnąć do źródeł i posłuchać o rozwiązaniach z samego serca Silicon Valley tak by nie wynajdywać na nowo koła budując własny portal:). Polecam Velocity dla wszystkich zainteresowanych tematyką wydajności stron www.

Jako ciekawostkę wrzucam link do dokumentu opisującego instalację BIG-IP v4.5.10 na Bladzie IBMa HS20. Tak, żeby było wiadomo, że da się;).

Musiałem przeczyścić bazę ze SPAMerskich komentarzy, możliwe że przy okazji poleciały też komentarze od czytających mojego bloga. Jeżeli ktoś czuje sie pokrzywdzony to proszę o ponowny komentarz;).

Przy okazji czyszczenia bazy ze spamu, trafiłem na perełkę. Waldemar Duszyk podał link do swojej stronki domowej, gdzie można poczytać o AIXie. Idealna stronka dla osób startujących z AIXem – http://www.wmduszyk.com.