Archiwum z Marzec 2009

MS-2199 + FSAE

wtorek, 31 Marzec 2009

Pod koniec zeszłego tygodnia brałem udział w szkoleniu Fortinet Server Authentication Extensions (FSAE) + MS-2199 Active Directory Fundamentals. Jak większość technicznych szkoleń, w których ostatnio uczestniczę, organizowało je Compendium Centrum Edukacyjne Sp. z o. o.; prowadzenie: Daniel Guga.
Zdecydowanie polecam tego człowieka, jeśli chodzi o szkolenia Microsoft. Wiedza teoretyczna poparta dużą praktyką – nie ma trudnych pytań, na wszystkie problemy, z którymi ja spotkałem się miał odpowiedź – gotowe rozwiązanie lub jakieś obejście.
W temacie FSAE (Fortinet) był mniej biegły, co sprawiało wrażenie, że poznał FSAE dla potrzeb szkolenia, no ale w gruncie rzeczy zbyt wiele z tym się nie da zrobić i nawet po takim przedstawieniu sprawy każdy powinien dać radę tym zarządzać (ja męczę to od blisko pół roku, więc conieco już o tym wiem).

Generalnie jadąc na jakiekolwiek szkolenie polecam zapoznać się z tematem dużo wcześniej, poklikać samemu, poszukać w sieci rozwiązań i dopiero wtedy spotkać się z praktykującym teoretykiem.

A teraz o wszystkim co było dookoła. Miejsce: Kraków, czyli atrakcji moc. Czas trwania: 2 dni, więc niezbędny nocleg. Gdzie? Oczywiście w hostelu Kadetus. Na wejściu recepcjonistka przeprosiła mnie za remont ‘Jokera’ i dostałem (prawie) apartament. Nie mam nic przeciwko, by remontowali tam zawsze jak będę ich odwiedzał ;-) Po powrocie, przedstawiając delegację zostałem wezwany i słyszę z ust sekretarki: „Bartku, tutaj jest błąd. Wpisałeś 35 PLN :-D”. No cóż. Niektórzy muszą mieć trzy cyfry, by się wyspać…

FortiAnalyzer 100B

poniedziałek, 23 Marzec 2009

Przyszła nowa zabawka ;-) Nie ma mnie…

0x1D

poniedziałek, 23 Marzec 2009

W związku z dość często pojawiającym się ostatnio pytaniem „Co w tym roku?” – odpowiem krótko: jedną z moich ulubionych płyt, której nigdy nie miałem.

MRTG – szukanie wąskich gardeł

piątek, 20 Marzec 2009

Używam MRTG (Tobi Oetiker’s MRTG – The Multi Router Traffic Grapher) od zawsze i ściągam dane z wszystkiego co może takowe udostępniać via SNMP. Niemniej domyślny plik konfiguracyjny tworzony przez cfgmaker może być niewystarczający do monitorowania sieci. Przede wszystkim porty, które są operationally DOWN są zakomentowane. Podejście dobre, jeśli chcemy monitorować tylko te porty, do których wpięte jest cokolwiek i sieć nam się nie zmienia. U mnie występuje dużo zmian, kable przepinane są z gniazdka do gniazdka, VLAN’y rozszerzają się i zwężają, itp., a nie chce mi się za każdym razem generować nowego pliku czy edytować istniejącego. Dlatego przy generowaniu pliku konfiguracyjnego polecam przełącznik --no-down. Jak czytamy w pomocy:

Options:
–no-down do not look at admin or opr status of interfaces

czyli wszystkie interfejsy pojawią się w pliku (z wyłączeniem specjalnych, dla których prędkość określona jest jako 0; można je ująć też korzystając z --zero-speed=spd).

Wynik na tym etapie może być dobry dla pojedynczego urządzenia z małą ilością portów – wykresy ładnie się skalują i zawsze na nich coś jest, nawet gdy sporo odbiegają od MaxBytes. Gdy jest więcej do oglądania nie zawsze chce mi się sprawdzać czy 70%, które widzę jest z 10 kbps czy z 1 Gbps. Włączam Unscaled i zawsze u góry jest MaxBytes. W takim wypadku wystarczy jeden rzut oka na stronę wygenerowaną przez indexmaker i widzę, że gdzieś może się zapychać.

MaxBytes jest niewygodne w momencie gdy do zmieniamy prędkość portu – np. z 100 Mbps na 1 Gbps. Wtedy wyższe wartości są ignorowane, co rzutuje na dane do wykresu. Z kolei ustawianie wszystkim portom prędkości na największą możliwą nie pokaże kiedy ‘zapcha’ się połączenie, które pracuje na niższej prędkości. Jeszcze nie znalazłem bezobsługowego obejścia tego (prócz okresowego generowania nowego pliku).

W środowisku bez DNS można użyć opcji --noreversedns by przyspieszyć operację (niezauważanie).

Po takim tuningu zapominam o plikach konfiguracyjnych i tylko czasami oglądam wykresy.

IEEE 802.3ad

środa, 18 Marzec 2009

15:07 <@s1m0n> guzik: widze, ze tez ostro sie wkrecasz w macierze;]
15:09 <@s1m0n> MPIO i JF widze juz ruszyles, moze zainteresuje cie tez LACP - http://en.wikipedia.org/wiki/Link_aggregation

W sumie – czemu nie. Choć początkowo myślałem, że link aggregation robi się tylko celem zwiększenia prędkości połączeń, ale okazało się, że jestem gdzieś w tyle i w ogóle niedouczony. IEEE 802.1AX-2008 (IEEE 802.3ad) oprócz możliwości użycia wielu portów / kabli równolegle celem zwiększenia prędkości połączenia pozwala na redundancje tychże połączeń.

lacp_broadcom01No to ziu! Upewniłem się, że przełączniki wspierają LACP (3Com 2924-SFP Plus, 3Com 2948-SFP Plus). Wziąłem pierwszy z brzegu serwer (maszyna, która się jeszcze ‘wygrzewa’) – ma dwie karty Broadcom 5708C. Standardowy sterownik z Windows 2003 (4.4.11.0) zaktualizowałem do 4.6.15.0. Zainstalowałem oprogramowanie do zarządzania – Broadcom Advanced Control Suite 11.6.10.0 (wymaga .NET Framework 2.0), bo Windows 2003 (podobno) nie wspiera natywnie LACP. Stworzyłem odpowiedni team i działa:

C:\Documents and Settings\Administrator>ipconfig
Windows IP Configuration
Ethernet adapter Team 1:
Connection-specific DNS Suffix  . :
IP Address. . . . . . . . . . . . : 192.168.1.200
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.176

lacp_intel01Pełen zapału wziąłem się za serwer produkcyjny (zdalnie!) z kartami Intel(R) PRO/1000 PM i Intel(R) PRO/1000 PL (ta pierwsza nie wspiera Jumbo Frames). Niestety po połączeniu ich maszyna przestała odpowiadać. Już lokalnie sprawdziłem, że nowy interfejs ma adres nadany przez APIPA (169.254/16). Być może przepisał go z drugiego interfejsu, który w momencie konfiguracji był wyłączony. Broadcom przepisał adres z karty oznaczonej jako Primary. No ale ostatecznie zadziałało i mogłem potestować.

lacpNie sprawdzałem obciążenia, bo nigdy nie było to wąskim gardłem w naszej sieci. Testowałem losowe wypinanie kabli i wypadło nieźle, ale nie niezauważalnie. Może to przypadek, ale przepinanie z Primary na Secondary idzie szybciej niż w drugą stronę. Wpinanie dwóch kart do jednego przełącznika z punktu widzenia SPOF nie ma sensu, ale przełączanie ruchu pomiędzy interfejsami jest w takim przypadku oczywiście szybsze niż gdy karty są wpięte do różnych przełączników w kaskadzie (testowałem w środowisku jak na schemacie obok).

Nie testowałem agregacji w innych systemach operacyjnych, ale na pierwszy rzut pójdzie wkrótce Linux (bonding).

Symbol: BONDING [=n]
Prompt: Bonding driver support
Defined at drivers/net/Kconfig:60
Depends on: NET && INET
Location:
-> Device Drivers
-> Network device support

Na stworzonych team‘ach można tworzyć VLAN’y, więc mimo połączenia dwóch (lub więcej) kart ruch można potem rozdzielić.

QLogic 2312 + Linux

środa, 18 Marzec 2009

Jako, że zacząłem budowę SAN i podłączam do niej wszystko co możliwe, padło też na serwer z Linux. Zainstalowana jest w nim karta, która przedstawia się następująco:

08:03.0 Fibre Channel: QLogic Corp. ISP2312-based 2Gb Fibre Channel to PCI-X HBA (rev 02)
Subsystem: QLogic Corp. Device 0100
Flags: 66MHz, medium devsel, IRQ 21
I/O ports at 2000 [disabled] [size=256]
Memory at b8a00000 (64-bit, non-prefetchable) [disabled] [size=4K]
Expansion ROM at b8b00000 [disabled] [size=128K]
Capabilities: [44] Power Management version 2
Capabilities: [4c] PCI-X non-bridge device
Capabilities: [54] Message Signalled Interrupts: Mask- 64bit+ Count=1/8 Enable-
Capabilities: [64] CompactPCI hot-swap <?>
Kernel modules: qla2xxx

W jądrze:

Symbol: SCSI_QLA_FC [=m]
Prompt: QLogic QLA2XXX Fibre Channel Support
Defined at drivers/scsi/qla2xxx/Kconfig:1
Depends on: PCI && SCSI
Location:
-> Device Drivers
-> SCSI device support
-> SCSI device support (SCSI [=y])
-> SCSI low-level drivers
Selects: SCSI_FC_ATTRS && FW_LOADER

Załadowanie samego modułu (jądro > 2.6.18) jeszcze nie zmusi karty do pracy, w dmesg powinien pojawić się taki komunikat:

QLogic Fibre Channel HBA Driver
GSI 21 sharing vector 0xC8 and IRQ 21
ACPI: PCI Interrupt 0000:08:03.0[A] -> GSI 24 (level, low) -> IRQ 21
qla2xxx 0000:08:03.0: Found an ISP2312, irq 21, iobase 0xffffc20000016000
qla2xxx 0000:08:03.0: Configuring PCI space...
qla2xxx 0000:08:03.0: Configure NVRAM parameters...
qla2xxx 0000:08:03.0: Verifying loaded RISC code...
qla2xxx 0000:08:03.0: Firmware image unavailable.
qla2xxx 0000:08:03.0: Firmware images can be retrieved from: ftp://ftp.qlogic.com/outgoing/linux/firmware/.
qla2xxx 0000:08:03.0: Failed to initialize adapter

Po zastosowaniu się do wskazówek (pobraniu z podanej lokalizacji odpowiedniego pliku, w moim przypadku ql2300_fw.bin i skopiowaniu go do /lib/firmware) powinno zadziałać jak należy (Firmware Loader zrobi wszystko za nas):

QLogic Fibre Channel HBA Driver
PCI: Enabling device 0000:08:03.0 (0150 -> 0153)
ACPI: PCI Interrupt 0000:08:03.0[A] -> GSI 24 (level, low) -> IRQ 21
qla2xxx 0000:08:03.0: Found an ISP2312, irq 21, iobase 0xffffc20010098000
qla2xxx 0000:08:03.0: Configuring PCI space...
qla2xxx 0000:08:03.0: Configure NVRAM parameters...
qla2xxx 0000:08:03.0: Verifying loaded RISC code...
qla2xxx 0000:08:03.0: Allocated (412 KB) for firmware dump...
qla2xxx 0000:08:03.0: Waiting for LIP to complete...
qla2xxx 0000:08:03.0: Cable is unplugged...
scsi2 : qla2xxx
qla2xxx 0000:08:03.0:
QLogic Fibre Channel HBA Driver: 8.01.07-k1
QLogic QLA2340 -
ISP2312: PCI-X (133 MHz) @ 0000:08:03.0 hdma+, host#=2, fw=3.03.27 IPX

iSCSI i Jumbo Frames

wtorek, 17 Marzec 2009

Parę odnośników w temacie SAN (i Jumbo Frames):

Mnie jakoś brakło zapału, żeby forsować iSCSI – używamy SAS dla DAS i FC dla SAN.

clipboard013Przełączniki, których używamy mają wsparcie dla Jumbo Frames, aczkolwiek liczyłem na to, że gdzieś jest możliwość przestawienia (wymuszenia) tego. Nie wiem czy statystyki cokolwiek pokazują, bo i 1’500 i 9’000 bajtów zawiera się w „Frames of 1024 to 9216 Bytes„. Tak czy inaczej w niektórych kartach poprzestawiałem, bo domyślnie było 1’500, mimo, że nigdy nie było to wąskim gardłem w naszym systemie.