Tomasz Wendlandt

Ciekawy blog na temat Blade’ów.

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.