Partnerstwo firm Citrix i Microsoft było burzliwe i interesujące od zawsze - niezależnie od tego, czy w modzie były akurat usługi terminalowe, czy wirtualizacja i chmury obliczeniowe. Wielu zadaje sobie pytanie, czy na dłuższą metę da się współpracować oferując niemalże identyczne produkty na wąskim jak by nie patrzeć rynku, w tym przypadku hypervisorów?

Oczywiście, że się da - tak odpowiada na swoim blogu sam CTO działu Data Center & Cloud w Citriksie. Simon Crosby opublikował krótką notatkę, w której wyraźnie, pogrubioną czcionką podkreśla: Citrix nie konkuruje z Microsoftem. Nie wiem, czy ktoś w to uwierzy, ale według Crosbiego XenServer nie jest bezpośrednią konkurencją dla Hyper-V. Żadna z firm nie chce zarabiać na hypervisorze - dodaje. XenServer jedynie zapewnia zestaw funkcji niezbędnych do umożliwienia Citriksowi i Microsoftowi rywalizacji z VMware.

Ciekawe jest też stwierdzenie, że jeśli użytkownik wybierze dzisiaj XenServer, bo Hyper-V nie posiada pewnych funkcji (a swoją drogą, jest takich wiele...), to Citrix nie będzie miał nic przeciwko przyszłej migracji na Hyper-V, gdy produkt ten będzie bardziej rozbudowany i dojrzały. XenServer jest bowiem w 100% kompatybilny z Hyper-V, co Citrix często, a Microsoft rzadziej podkreśla. W międzyczasie obie firmy korzystają w rywalizacji z naszym wspólnym konkurentem - podsumowuje Crosby. Niewątpliwie. Mogę też zapewnić, że udostępniamy Microsoftowi całą nasza wiedzę o tym, jak budować wspaniałą platformę wirtualizacyjną. Cóż, obecnie może faktycznie Hyper-V prezentuje się tak blado, że nie jest konkurencją dla XenServera, ale po tym, jak Microsoft wdroży rozmaite technologie Citriksa w swoim hypervisorze (na przykład IntelliCache - to już jest w planach) sprawa może się nieco zmienić.

Widać duży zapał do współpracy, trudno jednak nie oprzeć się wrażeniu, że jest on mocno jednostronny... Citrix z pewnością planuje wykorzystać ogromną bazę użytkowników Windows, dla których Hyper-V jest bardziej naturalny. Po niedawnym przeorientowaniu firmy na wirtualizację desktopów i chmury obliczeniowe, to, jaki hypervisor obsługuje XenDesktopa znacznie straciło na znaczeniu. Może to być więc i XenServer, i Hyper-V. Plan, pomimo tego, co pisze na blogu Simon Crosby, wydaje się więc dość czytelny. Pytanie tylko, czy Citrix zapatrzony w te plany przypadkiem nie piłuje gałęzi, na której jakiś czas temu całkiem wygodnie usiadł?

Dla operatorów telekomunikacyjnych i dużych dostawców treści peering to zwykle oszczędności, redundancja, oszczędności, wygoda i oszczędności. Największe polskie punkty wymiany ruchu IP, z PLIX na czele, skupiają niemal wszystkich liczących się uczestników polskiego (i nie tylko polskiego) Internetu. Na liście obecności brakuje oczywiście jednego z nich - Telekomunikacji Polskiej. TP na zasadach otwartego peeringu z mniejszymi wymieniać się ruchem nie chce. Ma jednak nową, bardzo ciekawą propozycję - 1 listopada startuje jej własny punkt wymiany ruchu, TPIX i nowa oferta telehousingu. Czy to spełnienie marzeń, czy tylko dobry PR?

Zanim na temat, pozdrowienia z piątego spotkania Polish Network Operators' Group w Krakowie. To właśnie tutaj, kilka godzin temu przedstawiciele Telekomunikacji Polskiej ogłosili nową ofertę. 1 listopada oficjalnie startuje punkty wymiany ruchu IP prowadzony przez TP - TPIX. Jego uczestnikiem będzie mógł zostać każdy, kto doprowadzi swoje łącza do switcha TPIX. Koszt gigabitowego portu to 1000 złotych miesięcznie, czyli opłata na całkiem przyzwoitym, rynkowym poziomie. Fizycznie TPIX będzie znajdować się w trzech miejscach w Warszawie - głównym punktem jest datacenter przy ulicy Nowogrodzkiej, gdzie sprzedawane będą dodatkowo także porty 10 GbE, a ponadto usługa dostępna będzie w budynku przy ulicy Pięknej oraz w serwerowni PLIX w Centrum LIM, bodaj najbardziej newralgicznym punkcie polskiego Internetu. Oczywiście na Warszawie Polska się nie kończy. TPIX będzie dostępny także w kilkunastu większych miastach w Polsce, a jakby tego było mało, w ponad 300 kolejnych, mniejszych lokalizacjach. W tym ostatnim przypadku TP naliczy jednak 10 złotych za megabit opłaty za tranzyt ruchu do Warszawy. Również i ta cena nie jest jakoś specjalnie wygórowana. W końcu za 2000 złotych miesięcznie można być uczestnikiem węzła wymianu ruchu i peerować się z TP, a jak ktoś szczęśliwie kolokuje swoje maszyny w PLIX czy innym warszawskim datacenter, to nawet taniej. Gdzie jest haczyk?

To proste. Haczyk polega na tym, że zasady peeringu z TP tak naprawdę nie zmieniają się, ot i cała historia. Peering w wykonaniu TP nadal polega na płaceniu za każdy megabit pasma, i to płaceniu niemało. Ceny zaczynają się od około 30 złotych. Taki peering był już możliwy po podłączeniu się bezpośrednio do sieci TPNET, jednak gigabitowy port kosztuje tam 2000 złotych miesięcznie. W TPIX mamy dwa razy taniej, a dodatkowo TP oferuje nam możliwość swobodnej i bezpłatnej (w ramach portu) wymiany ruchu z innymi uczestnikami TPIX, a także możliwość (płatną 500 złotych miesięcznie za sztukę) zestawienia prywatnego VLANu z innym uczestnikiem w celu kupienia od niego bądź sprzedania mu konkretnej usługi. Pozwala to na przykład na zakup pasma u operatorów zagranicznych, tzw. operatorów Tier-1, którzy niebawem mają się w TPIX pojawić. Warto jednak zwrócić uwagę, że w TPIX w przeciwieństwie do usług zakończonych bezpośrednio na urządzeniach TPNET nie obowiązuje praktycznie żaden poziom SLA - usterka będzie naprawiona, ale TP nie deklaruje procentowego czasu dostępności usługi. Jeśli chcesz gwarancji, musisz płacić więcej.

I co - sen czy PR? Sen wcale nie, bo nadal wysyłanie ruchu do TPNET kosztuje niemało i TPIX raczej tego nie zmienia. PR trochę, ale chyba też nie do końca - ostatecznie oferta jest mimo wszystko atrakcyjna, zwłaszcza dla operatorów spoza Warszawy, którzy mogą skorzystać z rozbudowanego szkieletu sieciowego TP w Polsce i w ten sposób zacząć wymieniać się ruchem z wszystkimi poza TP. Niewątpliwie jednak TPIX to kubeł zimnej wody na rozgrzane głowy pasjonatów peeringu, którzy po cichu liczyli na rewolucję... o ile byli w ogóle tacy, bo temat otwartego peeringu z TP już jakiś czas temu zrobił się mityczny. Efektem tego jest to, że dostawcy treści wysyłają ruch do sporej przecież grupy użytkowników TP przez zagranicę po cenach rzędu kilku euro za megabit, co jest znacznie tańsze niż kupowanie megabitów do TPNET. TP natomiast raczej tylko na tym traci - w końcu ten ruch tak czy owak musi do nich trafić, może lepiej więc, gdyby sprzedali go bezpośrednio zainteresowanym? Musieliby co prawda zrobić to dużo taniej niż dzisiaj, ale ostatecznie wtedy zarobili by wszystko to, co dzisiaj zgarniają Level3, Global Crossing, Telia i inni...

Czy TPIX osiągnie sukces? Oczywiście! Chociażby dlatego, że wielu operatorom ułatwi dostęp do rynku IP, dla niektórych będzie po prostu kolejnym zapasem, a dla innych... zwyczajnie sprawą prestiżową. W końcu węzeł prowadzi największy polski operator.

Wirtualizacja jako taka to już pojęcie nie najnowsze, a wirtualizacja routerów? Wiele osób jeszcze niechętnie patrzy w stronę zastąpienia "sprawdzonych", sprzętowych routerów "uznanych producentów" czymś innym, czyli zwykle mimo wszystko mniej sprawdzonymi, choć niekoniecznie gorszymi rozwiązaniami programowymi - na przykład wykorzystywaną przez nas linuksową dystrybucją Vyatta. Takie rozwiązania mają właśnie tę niepodważalną zaletę, której sprzęt Cisco, Junipera czy kogokolwiek innego nie posiada - można je przenieść na hypervisor i tam tanim kosztem zapewnić redundancję, migrować "na żywo" pomiędzy serwerami czy skalować wraz ze wzrostem obciążenia. Pytanie tylko - jaki wybrać hypervisor?

Router jest szczególnym elementem każdej infrastruktury - zwykle gdy ten element zawodzi, nie ma sensu funkcjonowanie całej reszty, która za nim stoi. Migrację z Cisco 7140 na linuksową dystrybucję Vyatta przeprowadziliśmy z powodzeniem jeszcze w 2008 roku i byliśmy pod wrażeniem, jak Linux radzi sobie z przerzuceniem wówczas ponad 100 megabitów ruchu na low-endowym serwerze z procesorem Core 2 Duo. Rok później zdecydowaliśmy się na migrację większości infrastruktury do środowiska wirtualnego - w tej większości znalazła się też Vyatta (na marginesie, znalazło się w niej wszystko oprócz serwerów baz danych). Byliśmy ciekawi, czy system równie dobrze będzie funkcjonować jako maszyna wirtualna i czy sprosta surowym wymogom co do transferów i dopuszczalnych opóźnień. Okazuje się, że odpowiedź na to pytanie poznaliśmy dopiero teraz, po wypróbowaniu ostatniego hypervisora, czyli Citrix XenServer. Przysłowie "do trzech razy sztuka" było tu bardzo na miejscu :-)

Zacznijmy od początku i załóżmy, że interesują nas tylko bezpłatne hypervisory. Zanim odpowiem na tytułowe pytanie, zacznę od skreślenia Hyper-V. Nie ma co się oszukiwać - przy całej mojej sympatii i sentymentu do serwerowych rozwiązań Microsoftu niestety ten hypervisor nadal, po ponad dwóch latach od premiery i mimo zabiegów marketingowych producenta, nie nadaje się do wirtualizacji Linuksa. Obecnie nie ma jeszcze oficjalnie wspieranych przez Microsoft i Vyattę komponentów integracyjnych na kształt tych dostępnych u konkurencji, co praktycznie eliminuje Hyper-V z rozgrywki.

ESXi, a raczej VMware vSphere Hypervisor (niedawno przemianowany - żeby nazwa czasem nie była zbyt krótka, niż to dozwolone w korpo-polityce) prezentuje się tu dużo lepiej. Vyatta udostępnia prekonfigurowane obrazy maszyny wirtualnej w formacie OVF. Wszystko byłoby piękne, gdyby nie fakt, że bezpłatna wersja ESXi nie pozwalała na import takiej maszyny - przyznam, że nie wiem jak jest obecnie, bo od jakiegoś czasu ESXi już nie używam. To jednak też nie jest duży problem, bo można sobie pobrać obraz ISO płyty instalacyjnej w wersji dostosowanej do środowisk wirtualnych i po prostu zainstalować na czystej maszynie. To działa i działa nawet całkiem dobrze. Wraz ze wzrostem obciążenia ponad 150-200 Mbit/s pojawił się jednak dziwny problem: jakość komunikacji sieciowej z hostem ESXi, na którym działała Vyatta routująca taki ruch dramatycznie spadała. Przykładowo pobieranie instalatora vSphere Clienta przebiegało z prędkością mierzoną w bajtach na sekundę. Obserwowaliśmy także dużą stratę pakietów. Najgorsze jednak było to, że wszystkie maszyny wirtualne obok Vyatty na tym samym hoście również doświadczały tego problemu! Łączność była upośledzona jedynie "wewnątrz", czyli gdy ruch nie przechodził przez Vyattę. Mimo wszystko był to jednak ogromny problem. Nie rozwiązała go także zmiana typu wirtualnych kart sieciowych na Vyacie z zalecanych VMXNET3 na starsze E1000 - te drugie karty po prostu nie dawały rady i już przy ruchu ok. 100 Mbit/s przez brak offloadingu gotowały się procesory.

Zapoczątkowałem, jak się później okazało, bardzo interesujący wątek na forum Vyatty dotyczący powyższego problemu. Okazało się, że nie jesteśmy sami, choć początkowo Vyatta przerzucała ciężar sprawy na VMware. Na tamtejszym forum jednak nie uzyskałem w ogóle odpowiedzi. Po kilkunastu tygodniach diagnozowania problemu i rozmaitych, nieudanych prób zaczęło nam to doskwierać na tyle, że rozpoczęliśmy przymiarki do testów XenServer. Jak na ironię, gdy kończyliśmy już testy i praktycznie zdecydowaliśmy się na migrację, inżynierom Vyatty udało się ustalić, że problem podobno istotnie leży po stronie ESXi, a jego tymczasowym obejściem jest wyłączenie TCP Segmentation Offloading na kartach sieciowych VMXNET3, ale... nie na Vyacie, a na wszystkich maszynach wirtualnych stojących obok. Na dłuższą metę było to więc rozwiązanie dość karkołomne, a poza tym nie dało się tego zastosować na samym hoście ESXi. Najważniejsze jednak, że w międzyczasie XenServer wypadł w naszych testach bardzo pozytywnie i zdecydowaliśmy się migrować pomimo częściowego rozwiązania problemu z ESXi. Dla przyzwoitości dodam jedynie, że wydana kilka tygodni temu wersja VC6.1 Vyatty zawiera już wbudowaną poprawkę (a może raczej kolejne obejście) i problem nie powinien już być tak uciążliwy. Jeśli ktoś lubi łataninę, to po szczegóły odsyłam do wspomnianego wyżej wątku.

Po przetestowaniu wszystkich liczących się na rynku hypervisorów śmiało stwierdzam - XenServer jest najwygodniejszy jeśli chodzi o Vyattę. Wszystko działa tam jak należy (w tym XenMotion, bo XenServer ma go w wersji bezpłatnej!) i to nawet pod dużym obciążeniem. Nie trzeba też konfigurować niczego nadzwyczaj skomplikowanego. Wystarczy pobrać szablon XVA maszyny wirtualnej ze strony Vyatty, zaimportować go na serwer (co działa bez względu na typ licencji) i po prostu stworzyć na jego podstawie nową maszynę. Do dyspozycji jest tylko jeden typ wirtualnej karty sieciowej, więc nie można się pomylić. Po pierwszym uruchomieniu trzeba jedynie otworzyć w nano plik konfiguracyjny Vyatty znajdujący się w lokalizacji [i]/opt/vyatta/etc/config/config.boot[/i] i dopisać adres MAC do każdego interfejsu sieciowego. Powód? Vyatta osadza MAC w pliku konfiguracyjnym, a przecież budując szablon do pobrania dla wszystkich trudno było go przewidzieć... Aktualnie najnowszy (VC6.1) szablon XVA Vyatty ma wbudowane XenTools w wersji 5.5, więc jeśli mamy wydaną bardzo niedawno wersję 5.6 to trzeba zrobić aktualizację. Nie jest to jednak skomplikowane - montujemy /dev/xvdd czyli napęd CD z narzędziami XenTools i instalujemy pakiet .deb:

sudo mount /dev/xvdd /mnt
sudo dpkg -i /mnt/Linux/xe-guest-utilities_5.6.0-578_i386.deb 

Podczas wizyty na tegorocznym Citrix Synergy rozmawiałem z inżynierem Cisco, który notabene znał Vyattę bardzo dobrze. Pytałem go między innymi o to, dlaczego jeszcze nie zauważyli rosnącej popularności wirtualizacji i tego, że wirtualne linuksowe routery mogą w krótkim czasie nieźle namieszać na rynku. Jak można się było spodziewać, otrzymałem wymijającą odpowiedź, ale pewnie byłoby ciekawie, gdyby Cisco zaczęło sprzedawać wirtualne routery - pytanie tylko, jak by je wyceniło? Dopóki to jednak nie nastąpi, polecam zastanowić się nad wirtualizacją Vyatty na jednym z hypervisorów - u nas najlepiej sprawdził się XenServer. Jeśli macie jakieś pytania, chętnie odpowiem w komentarzach :-)

Po wielu miesiącach – udało się! Wyszukiwanie pełnotekstowe w SQL Server 2008 nareszcie działa tak, jak powinno.

O co chodzi? Minęło tak dużo czasu, że warto chociaż pokrótce przypomnieć – tuningując wyszukiwarkę na dobrychprogramach odkryliśmy całkiem ciekawy, niestety dość poważny błąd w wyszukiwaniu pełnotekstowym oferowanym przez SQL Server 2008. Błąd ten objawiał się tym, że często zwracane były niepełne rezultaty wyszukiwania – przy odpowiednich ustawieniach i pomimo poprawnego skonfigurowania polskich bibliotek językowych w większości przypadków baza nie była przeszukiwana pod kątem form fleksyjnych danego słowa. Więcej nie będę już pisał – po szczegóły, także bardziej techniczne i z metodą reprodukcji odsyłam do felietonu Full-Text Search po polsku szuka kiepsko, który opublikowałem tuż po napotkaniu problemu i zgłoszeniu go do pomocy technicznej Microsoftu.

Eskalacja problemu w pomocy technicznej była całkiem interesującym doświadczeniem – spotkaliśmy się chyba ze wszystkimi poziomami wsparcia. Problem zgłosiliśmy w styczniu. Polskę zgłoszenie opuściło już po jednym dniu, by mógł zająć się nim inżynier wsparcia z dalekiego wschodu (kraj nieustalony, ale różnica czasu +8h), a ostatecznie po kilku tygodniach sprawa trafiła do nieco bliższych Niemiec, skąd kolejny inżynier po namierzeniu problemu już bezpośrednio koordynował pracę zespołu produktowego w Redmond. Skala problemu okazała się na tyle duża, że postanowiono nadać jej najwyższy priorytet w nomenklaturze wsparcia technicznego Microsoftu i wypuścić poprawkę w tzw. modelu Critical On-Demand. Poprawka została oficjalnie wydana kilka dni temu pod numerem KB980350, my otrzymaliśmy ją pod koniec czerwca. Oznacza to, że rozwiązanie tego, jak oceniono, krytycznego problemu zajęło około pół roku.

Niewtajemniczeni mogliby pomyśleć, że trwało to tak długo, bo istota błędu znajdowała się nie w SQL Serverze czy innym oprogramowaniu Microsoftu, ale w bibliotekach do obsługi polskiego języka. Te z kolei dostarczane są od lat przez polską firmę TiP i Microsoft nie ma ich kodu, nie może niczego poprawić. Firmie TiP trudno jednak cokolwiek zarzucić i w tym miejscu chciałbym jej inżynierom gorąco podziękować. Sami skontaktowali się z nami kilka dni po publikacji felietonu w TechIT i od razu zainteresowali się tematem. Dzięki naszej bezpośredniej współpracy, zupełnie niezależnej od zgłoszenia w pomocy technicznej Microsoftu, udało się ustalić konkretną przyczynę problemu w bibliotece DLL i usunąć ją w ciągu kilkunastu dni. Już w lutym mieliśmy więc nową, nieoficjalną co prawda i oczywiście nieprzetestowaną bibliotekę, ale wstępne doświadczenia były bardzo pozytywne – wszystko działało tak jak trzeba. Dzięki temu nie musieliśmy czekać z założonymi rękami na Microsoft, który poprawkę – już oficjalną i przetestowaną – dostarczył znacznie później...

Podsumowując, pomoc techniczna Microsoftu działa dość skrupulatnie i, jakby nie patrzeć, skutecznie. Niestety czas nie idzie w parze z jakością – rozwiązanie problemu, który skutkował tak naprawdę bezużyteczną wyszukiwarką zajęło naprawdę masę czasu. Osobiście spodziewałem się kilku tygodni, ale nie kilku miesięcy. Trzeba jednak przyznać, wracając do tej jakości, że kontakty z inżynierami były na etapie badania sprawy bardzo rzeczowe i merytoryczne, a na etapie pracowania nad poprawką – częste i konkretne. Szkoda, że w większości były to komunikaty o kolejnych, przesuwanych terminach wydania poprawki...

Na koniec nasunął mi się jeszcze jeden wniosek z całej tej zabawy – pół roku prac poskutkowało poprawką dla SQL Server 2008. W międzyczasie jednak wyszedł SQL Server 2008 R2, a tam polski FTS też nie działa tak jak trzeba. Być może opracowanie poprawki do tej wersji serwera potrwa kolejne pół roku... Pozytywnym akcentem w tej sprawie jest jednak fakt, że za incydenty spowodowane faktycznym błędem w oprogramowaniu Microsoft nie nalicza opłaty (standardowo ponad tysiąc złotych) oraz nie odejmuje bezpłatnych incydentów z ewentualnie posiadanej puli.

Kolejny miesiąc i kolejne prośby, a nawet groźby ze strony IANA, RIPE i innych RIRów w sprawie migracji na IPv6 - adresy 32-bitowe kończą się szybciej, niż przewidywano jeszcze kilka miesięcy temu, więc jeśli nie zaczniemy od razu przygotowań do IPv6, czeka nas kompletny paraliż. Czy Twoja sieć jest już gotowa na IPv6? To na co jeszcze czekasz?

Śpieszę wyjaśnić - powyższy wstęp zawiera sporą dawkę ironii, bo trudno mi o inne emocje, gdy czytam tu i tam kolejne doniesienia o kurczących się wolnych blokach IPv4 i pozostałym czasie do godziny zero, a jednocześnie obserwuję reakcje uczestników Internetu i stan ich przygotowań. Niedawno statystykami pochwalił się ARIN, czyli amerykański RIR - organizacja zarządzająca adresacją IP w Ameryce Północnej. Raport z bieżącej sytuacji zdał sam dyrektor, John Curran, który poinformował, że pozostało niewiele ponad 6% adresów nieprzypisanych żadnemu RIRowi przez IANA, organizację sprawującą nad adresami IP (i nie tylko) nadzór ogólnoświatowy. 6% to 16 z 256 bloków klasy A, czyli tych największych zawierających około 16 milionów adresów (2 do potęgi 24). Jeszcze w styczniu tego roku wolnych było 10% adresów, ale podobno coś niespodziewanego wydarzyło się w regionie azjatyckim - okazało się, że zapotrzebowanie na adresy IP było tam w ostatnich miesiącach olbrzymie. Być może miało to wpływ na fakt, że w tym roku IANA zdążyła już przydzielić RIRom tyle samo bloków, co w całym roku 2009. Tempo jest więc faktycznie spore - najnowsze prognozy przewidują koniec adresów w grudniu tego roku.

Wolne bloki naprawdę się kończą, więc IANA nie ma wyboru i przydziela to, co zostało - między innymi to, co od wielu lat jest przeznaczone do różnych, głównie testowych potrzeb, na przykład blok 1.0.0.0/8. Bardzo chętnie jest on wykorzystywany w scenariuszach testowych i na schematach jako reprezentant zewnętrznych sieci. Co się stanie, gdy te adresy trafią do użytkowników końcowych można było zaobserwować podczas testów jakie przeprowadzili wspólnie APNIC (RIR z regionu Azja-Pacyfik), Uniwersytet Michigan i operator Merit łączący sieci uniwersyteckie w Australii. Do celów testowych cały blok 1.0.0.0/8 został rozgłoszony przez routery Meritu. Efekt? 150 megabitów ruchu, głównie UDP. Ciekawostką jest fakt, że większość tego ruchu to pakiety VoIP z nieskonfigurowanych telefonów. Dla porównania rozgłoszono także blok 35.0.0.0/8 i tam ruchu było już tylko 15 megabitów, tym razem raczej TCP. W rezultacie przeprowadzonych testów APNIC zdecydował poddać kwarantannie pięć bloków klasy C (przede wszystkim 1.1.1.0/24) do czasu unormowania sytuacji - w praktyce jednak tych adresów pewnie już nigdy nie da się uwolnić. Zainteresowanych szczegółami testów odsyłam do slajdów ze spotkania North American Network Operators Group.

A co na to wszystko operatorzy i dostawcy treści? Ani jedni ani drudzy nie wydają się przejęci. Organizacje zarządzające biją na alarm i apelują od lat, coraz intensywniej, o przygotowanie do IPv6, ale nikt tak naprawdę tego nie robi i prawdopodobnie prędko robić nie będzie. Również na naszym polskim podwórku sytuacja wygląda mizernie - drixter pisał w maju 2009 na łamach naszego serwisu o możliwości uzyskania adresacji PI IPv6 w RIPE. Mając już swój blok, notabene liczony w bilionach adresów (minimalna alokacja PI to /48), można zostać uczestnikiem jednego z dużych krajowych węzłów wymiany ruchu i dzięki BGP dołączyć do grona szczęśliwych użytkowników dynamicznego routingu IPv6 w Polsce, którzy... niestety są skazani wyłącznie na siebie i kilka kilobitów ruchu kontrolnego BGP, bo w polskim IPv6 trudno póki co nie tylko o wyjście na świat, ale także o jakiegokolwiek sensownej wielkości operatora czy dostawcę treści, który pozwoliłby nam IPv6 wykorzystać.

Niestety nic nie wskazuje na to, by miało się to szybko zmienić - albo i "stety", zdania podzielone. Wielu uważa bowiem IPv6 za protokół bez przyszłości. A koniec roku coraz bliżej...

Wierzyć się nie chce, że przez ładnych kilka lat całkiem poważny moim zdaniem błąd w wyszukiwaniu pełnotekstowym SQL Servera nie został przez nikogo dostrzeżony, a raczej zgłoszony do Microsoftu – bo być może ktoś zauważył, że Full-Text Search zwraca czasem różne zestawy wyników, ale nie miał możliwości, czasu lub chęci by problem eskalować. My zadaliśmy sobie ten trud, bo wyszukiwarka jest bardzo ważnym elementem wszystkich naszych witryn i powinna działać dobrze. Okazało się, że faktycznie obsługa polskiego języka w FTS jest zrobiona po prostu źle.

Czasy, gdy do wyszukiwania w bazach danych używało się predykatu LIKE chyba już minęły – tam, gdzie ruch w wyszukiwarce liczy się w zapytaniach na sekundę, a tabele zawierają miliony rekordów zwykły LIKE po prostu się nie sprawdza. Również sama precyzja wyników nie jest w takim scenariuszu zadowalająca. Po to wymyślono wyszukiwanie pełnotekstowe, by całą treść zaindeksować, a wyszukiwanie przebiegało błyskawicznie i na dodatek bardziej „inteligentnie”. W MySQL, z którego korzystaliśmy w dobrychprogramach przez całe lata wyszukiwania pełnotekstowego najpierw nie było, a później jak już było, to prezentowało się bardzo blado. Wraz z niedawną migracją na ASP.NET nie było już jednak żadnych przeszkód, by zaprząc do pracy wbudowany w SQL Server i rozwijany od dawna Full-Text Search, a od kilkunastu tygodni bardziej intenstywnie pracujemy nad tym, by wyniki były bardziej adekwatne do oczekiwań pytających.

Full-Text Search w SQL Server 2008 (skupmy się na tej wersji, bo tej właśnie używamy) oferuje dwa predykaty służące do odpytywania indeksu FTS. Pierwszy z nich, CONTAINS, bardzo przypomina LIKE, bo wykonuje dopasowanie wyrazu lub jego prefiksu (lub kilku wyrazów/prefiksów). Tak na marginesie, od lat klienci na całym świecie żądają od Microsoftu wprowadzenia możliwości wyszukiwania po sufiksach (czyli wpisując „office” dostajemy też „openoffice”), ale funkcji tej nadal nie ma i nie wiadomo, czy będzie. Obejściem problemu jest trzymanie w oddzielnej kolumnie tego samego tekstu, tyle że pisanego od prawej do lewej (pomaga w tym wbudowana funkcja REVERSE), dzięki czemu szukanie po prefiksie daje nam efekt jakbyśmy szukali po sufiksie. Generalnie CONTAINS dość dobrze sprawdza się do dokładnego wyszukiwania bardzo konkretnych wyrazów czy krótkich fraz. Do wyszukiwania kontekstowego, w obszernych tekstach bardziej nadaje się predykat FREETEXT. Szuka on wystąpień całych wyrazów, a ponadto umożliwia szukanie form fleksyjnych danego wyrazu czy nawet jego synonimów (jeśli wcześniej skonfigurujemy tezaurus). Szukamy frazy „zarządzanie siecią” i dostajemy dokument „o zarządzaniu sieciami” – całkiem sensowne, ani LIKE ani CONTAINS nie zwróci nam takich wyników i to w tak szybkim czasie.

Niestety gdy zaczęliśmy implementować FREETEXT pojawiły się pewne problemy. SQL Server raz zwracał pełen zestaw wyników, czyli wystąpienia danego słowa i jego wszystkich form fleksyjnych, a raz po prostu ignorował formy fleksyjne i szukał tylko ściśle tej formy, jaka została wpisana w wyszukiwarce. Trwające kilka dni intensywne próby debugowania problemów spełzły na niczym, a że akurat była okazja, zgłosiliśmy problem bezpośrednio do pomocy technicznej Microsoftu. Problem szybko został eskalowany do grupy produktowej SQL Servera i przez trzy tygodnie kilku inżynierów dość intensywnie pracowało (także zdalnie na naszych serwerach) nad ustaleniem przyczyny.

Dopiero dzisiaj otrzymałem e-mail, w którym ostatecznie uznano problem za zbadany – to znaczy udało się opracować obiektywną metodę jego reprodukcji. Za przyczynę wstępnie uznano polski word-breaker, komponent odpowiedzialny za przetwarzanie i przygotowywanie wpisanej frazy do wyszukiwania. Dzięki poleceniu sys.dm_fts_parser udało się ustalić, że czasami word-breaker po prostu nie generuje form fleksyjnych i dlatego nie są one wyszukiwane w indeksie. Co ciekawe, obsługa języka polskiego w Full-Text Search nie jest realizowana przez Microsoft – wraz z SQL Serverem dostarczane są biblioteki tworzone przez polską firmę TiP i trzeba je ręcznie włączyć w rejestrze postępując według instrukcji na stronach MSDN. Podobnie jest z językiem duńskim i tureckim, resztę języków robi już bezpośrednio Microsoft.

Jak zreprodukować problem? Trzeba utworzyć sobie bazę danych z tabelą i jakimś przykładowym tekstem (trzeba oczywiście zadbać o umieszczenie odpowiednich form fleksyjnych - dla przykładu niech będzie to wyraz "system" i formy "systemowi", "systemów" itp.), a następnie załączyć na tej tabeli FTS z polskim językiem na domyślnych ustawieniach. Przed testem należy zrestartować SQL Server i na takim czystym środowisku odpalić polecenie:

USE Baza
GO

DECLARE @i int
SET @i=1

WHILE @i < 10000
BEGIN
   SELECT * FROM dbo.Tabela WHERE FREETEXT(Kolumna, 'system')
   SET @i=@i+1
END
GO

Czasami już wtedy widać rezultaty w postaci nieprawidłowych wyników - zwracane są tylko wiersze zawierające "system", w wynikach nie ma wyrazów "systemowi", "systemów" itp. Jeśli wszystko jest OK, to w trakcie wykonywania tej pętli w drugim oknie edytora należy wykonać to samo zapytanie, tyle że już bez instrukcji WHILE. W tym momencie wyniki zwracane w jednym lub drugim oknie na pewno już będą nieprawidłowe. Stan taki utrzymuje się jakiś czas, by po chwili znów zwracane wyniki były poprawne. Znowu jednak wystarczy kilka kolejnych zapytań, by otrzymywane rezultaty były niewłaściwe.

Brzmi dość magicznie i trochę to trwało, zanim inżynierowie z pomocy technicznej uwierzyli :-) Zobaczyć znaczy jednak uwierzyć i teraz czekam na kontakt, co dalej – błąd został potwierdzony, tylko rozwiązania póki co brak... Miejmy nadzieję, że uda się coś na ten problem poradzić. Jak tylko otrzymam jakieś konkretne informacje od Microsoftu, dam oczywiście znać :-)

Jeśli jesteś administratorem serwera WWW, to prawdopodobnie wiesz, czym jest ETag. Nie wszyscy jednak wiedzą, jak dokładnie ten mechanizm działa i czasem warto sprawdzić, czy aby w naszym środowisku działa zgodnie z przeznaczeniem - zdarza się, że drobne przeoczenie zmusza klientów do niepotrzebnego pobierania tony grafik i plików CSS, co wydłuża czas dostępu do strony i generuje niepotrzebny ruch sieciowy. Przez pewien moment sami mieliśmy z ETagiem do czynienia, co skłoniło nas do głębszej analizy, a przy okazji poznaliśmy kilka ciekawych faktów.

W skrócie, czym jest ETag? Jest to nagłówek HTTP wysyłany w odpowiedzi przez serwer WWW, który zawiera pewien ciąg znaków unikalny dla danej wersji konkretnego pliku. Kiedy pobieramy plik z serwera po raz pierwszy, zapisujemy razem z nim w pamięci podręcznej ten właśnie ETag i przy następnym wywołaniu tego pliku pytamy, czy na serwerze jest plik o innym ETagu niż posiadany przez nas. Jeśli tak (czyli jeśli plik się zmienił), to go pobieramy ponownie. Jeśli nie, to serwer odpowiada komunikatem 304 Not Modified i na tym wywołanie się kończy, a przeglądarka wie, że może śmiało użyć swojej kopii pliku.

No dobrze, to jak się liczy taki ETag? Jednoznacznej odpowiedzi na to pytanie nie ma :-) Każdy producent serwerów WWW robi to po swojemu, nie każdy jednak chętnie chce się nim dzielić ze światem. Ogólnie jednak oczywiście wiadomo, że wpływ na wartość tego parametru ma między innymi data modyfikacji pliku. W serwerach IIS, których używamy, dodatkowo po znaku ":" serwer umieszcza obliczaną przez siebie "wersję pliku". Trochę na ten temat można przeczytać w artykule KB922703, ale Microsoft nie publikuje szczegółów na temat swojego algorytmu ETagów.

Już na tym etapie administratorzy klastrów WWW mają mały problem - jeśli jest kilka frontendów, a każdy oblicza sobie samodzielnie i niezależnie ETag (przynajmniej jego drugą część), to przy założeniu, że klienci wpadają w losowy węzeł klastra mogą za każdy razem dostawać inne ETagi i w nieskończoność pobierać niepotrzebnie te same pliki. Ten problem jest dość dobrze znany, na blogu IIS.net został opisany jeszcze trzy lata temu i tak naprawdę w wersji 7.0 już nie istnieje. Domyślnie IIS 7.0 wpisuje bowiem "0" jako numer wersji, co eliminuje losowość i pozwala ujednolicić ETag na wszystkich węzłach. W starszych wersjach IIS numer "0" możemy natomiast wymusić (warto jednak zapoznać się wcześniej z linkowanym już przeze mnie wcześniej artykułem KB922703 oraz KB900245).

Do hostingu dobrychprogramów, TechIT, Gamikaze i wszystkich usług towarzyszących używamy Windows Server 2008, więc i IIS 7.0. Pomimo tego w pewnym momencie zauważyliśmy, że w przypadku niektórych plików z każdym wywołaniem ETag jest inny, a zapisując jego wartości doszliśmy do wniosku, że jest ich tyle, ile węzłów w klastrze NLB. Co się stało? Powód był oczywisty - te same pliki na różnych serwerach (tak, replikujemy zawartość WWW pomiędzy frontendami, co ma szereg naszym zdaniem dużych zalet i małych wad, o czym może kiedy indziej) mają różne daty. Jak to się jednak stało? Odpowiedź na to pytanie nie była już taka oczywista.

Ostatecznie okazało się, że w procesie kopiowania kolejnych wersji witryny z serwera deweloperskiego na produkcyjne wykorzystywany był protokół FTP, który kopiując plik zamienia datę modyfikacji na bieżącą. Dodając do tego fakt, że ostatecznym miejscem docelowym jest przestrzeń DFS (czyli kopiowane pliki wpadają na losowy węzeł) i to, że usługa DFSR nie replikuje metadanych plików takich jak daty, mieliśmy już kompletne rozwiązanie. Po kilku cyklach kopiowania część plików, na przykład style CSS, na każdym serwerze miała inną datę.

Rozwiązanie? Na początek trzeba ujednolicić daty na wszystkich serwerach. Później rozwiązań jest kilka. Najlepiej nie kopiować w ogóle niezmienionych plików, ale nie zawsze jest to rozwiązanie najprostsze. My pilnujemy po prostu, by wszystkie pliki kopiowane były przy pomocy SMB, który zachowuje daty modyfikacji (dla przyspieszenia procesu na wąskich łączach można całość wcześniej spakować). I życie stało się prostsze - także dla Waszych przeglądarek ;-)

Mieliśmy okazję zajrzeć na wrocławską edycję organizowanych w całym kraju połączonych minipremier Windows 7 i Windows Server 2008 R2 oraz procesorów Intel Core i5. Konferencja odbyła się w ubiegłym tygodniu we wrocławskim hotelu Scandic. Bardzo wyraźnie nakreślono tam wizje rozwoju na polskim rynku serwerowym zarówno Microsoftu, jak i Intela - po pierwsze "prawdziwe", ale nadal stosunkowo tanie serwery dla małych i nawet tych najmniejszych przedsiębiorstw, po drugie Windows Server 2008 R2 Foundation - nowe SKU serwerowego systemu dostępne w naprawdę niskiej cenie.

Spotkanie wpisywało się w ramy Intel Channel Conference i przeznaczone było przede wszystkim dla partnerów obu firm, resellerów i integratorów sprzętu. W związku z tym prezentacje prowadzone przez przedstawicieli Microsoftu i Intela miały charakter bardziej marketingowy niż techniczny, niemniej nie obyło się bez kilku ciekawostek. Intel promował przede wszystkim tanie rozwiązania serwerowe - badania zaprezentowane przez Microsoft pokazały, że na 301 ankietowanych firm nadal 100 nie miało żadnego serwera, a wiele pozostałych funkcjonowało w oparciu o serwer na... Windows XP Professional. Nietrudno się domyślić, że takie maszyny to zwykle standardowe desktopy nieprzystosowane do ciągłej, serwerowej pracy. Intel demonstrował więc, jak za tysiąc dolarów dzięki tanim procesorom z serii Xeon 3400 (Nehalem ze zintegrowanym kontrolerem pamięci Dual Channel) skompletować towerowy serwer z serwerowym systemem operacyjnym. Zwrócono także uwagę na obniżkę dystrybucyjnych cen modułu do zarządzania Remote Management Module 3 (RMM3) z 50 do 25 dolarów.

Tysiąc dolarów z pewnością byłby przekroczony, gdyby nie równoczesne wprowadzenie na rynek przez Microsoft nowej edycji SKU systemu Windows Server 2008 R2 oznaczonej jako Foundation. Pisaliśmy o tej wersji na łamach TechIT jeszcze gdy była planowana - w skrócie jest to okrojona wersja Windows Server 2008 R2 dostępna tylko w kanale OEM, gdzie każde konto użytkownika musi być powiązane z fizyczną osobą. W systemie tym wprowadzono limit 15 użytkowników. Nie wymaga się za to w ogóle licencji dostępowych CAL. Na pokładzie nie ma też hypervisora. Najważniejsza jest jednak cena, która na naszym rynku wynosi około 400 złotych netto. Co ciekawe, Foundation trafił do Polski rzutem na taśmę - początkowo korporacja nie chciała go do nas wprowadzać tłumacząc, że nasz rynek jest już "dostatecznie rozwinięty". Polski oddział dopiął jednak swego przewidując u nas popyt na taki tani system i ostatecznie znalazł się jednak na polskim rynku i to także w polskiej wersji językowej.

Czy Windows Server 2008 R2 Foundation rzeczywiście, tak jak wierzy polski oddział Microsoftu, okaże się strzałem w dziesiątkę na naszym rynku? Wydaje się, że potencjał jest spory - jeśli mikro i małe firmy zdecydują się na zakup tanich serwerów, to prawdopodobnie kupią też nowy tani system Microsoftu. Ostatecznie jego cena jest porównywalna z biznesowymi wersjami systemów desktopowych, a możliwości jednak - pomimo ograniczeń - nieco większe. Czekamy na Wasze komentarze i opinie na ten temat.

Vizioncore to jeden z wystawców tegorocznej konferencji VMworld. Naszą uwagę na tę firmę zwrócił w e-mailu nasz stały czytelnik i musimy przyznać, że narzędzia do wirtualizacji opatrzone tym logiem zaciekawiły nas na tyle, że uznaliśmy temat jako warty poruszenia w serwisie - pomimo tego, że narzędzia te nie zostały wydane wczoraj.

Jeśli ktoś nie zna rozwiązań tej firmy, niech nie sugeruje się podobną do produktów VMware nazwą. Narzędzia te w większości działają ze wszystkimi najwazniejszymi (ESX/ESXi, XenServer, Hyper-V) platformami wirtualizacyjnymi, a co najważniejsze - sporo jest bezpłatnych. W ofercie darmowych narzędzi wirtualizacyjnych Vizioncore są trzy pozycje: vConverter SC, vControl Multi-Hypervisor Management i vOptimizer WasteFinder.

vConverter SC to jak nietrudno się domyślić narzędzie do konwersji P2V i V2V. Narzędzie to jest kompleksowe - oferuje opcje konwersji zarówno serwerów fizycznych do maszyn wirtualnych, jak i istniejących maszyn wirtualnych jednego formatu (producenta) do drugiego. Najważniejsze jest to, że obsługiwane są maszyny zarówno ESX/ESXi, XenServera i Hyper-V. Spotkaliśmy wiele komentarzy użytkowników, którzy zachwalali vConverter jako lepszy od znanego rozwiązania VMware o podobnej nazwie.

Kolejne bezpłatne narzędzie to vControl Multi-Hypervisor Management udostępniający webową konsolę do zarządzania wieloma hostami i maszynami wirtualnymi, z interfejsem dla użytkowników umożliwiającym samodzielne tworzenie maszyn wirtualnych według zdefiniowanych administracyjnie szablonów. Podobnie jak pozostałe programy, obsługuje wszystkie trzy hypervisory i dodatkowo Sun Solaris Zones. Kto ma Hyper-V i ESXi i narzeka na brak możliwości zarządzania wszystkim z poziomu jednej konsolki, powinien zainteresować się bezpłatnym vControlem.

W zestawie trzech bezpłatnych programów od Vizioncore jest też vOptimizer WasteFinder, który analizuje magazyn danych VMware vCenter pod kątem możliwych optymalizacji. Bezpłatna wersja oferuje dwie operacje optymalizacyjne: ustalenie właściwego rozmiaru dla maszyn wirtualnych, którym kończy się przestrzeń dyskowa oraz wyrównanie maszyn na partycji do 64K.

Tak jak pisałem, narzędzia te nie są nowe - najnowsze wersje pochodzą w większości z lipca. Polecamy jednak wszystkim administratorom środowisk wirtualnych przyjrzeć się, co też Vizioncore może w tym temacie zaoferować - po pierwsze ze względu na wieloplatformowość i bezpłatną licencję narzędzi, po drugie ze względu na całkiem spore jak na wersje bezpłatne możliwości.

W komentarzach do mojego poprzedniego wpisu poświęconego tematowi licencjonowania wirtualnych procesorów pojawiło się kilka interesujących uwag. Po pierwsze, postawiono tezę, że Hyper-V potrafi zapewnić wydajność kilku procesorów fizycznych w jednym wirtualnym, więc nie ma potrzeby przypisywania kilku wirtualnych CPU do maszyny. Po drugie, zwrócono mi uwagę na obecność eksperymentalnego parametru w ESXi 4.0 umożliwiającego połączenie kilku wirtualnych procesorów w jeden. Obie rzeczy wydały mi się na tyle interesujące, że pokusiłem się o mini-testy i porównanie wydajności zarówno w przypadku Hyper-V R2, jak i ESXi 4.0. Przy okazji testów wyszedł jeszcze jeden nieciekawy mankament bezpłatnej licencji ESXi 4.0 - brak obsługi ośmioprocesorowych maszyn wirtualnych...

Nie uprzedzajmy jednak faktów. Na pierwszy ogień weźmy temat obsługi procesorów w Hyper-V poruszony w komentarzach przez naszego czytelnika, jendrasa. Teza jak dla mnie była dość zaskakująca i, przyznam szczerze, mało racjonalna - mimo tego postanowiłem to sprawdzić. Ostatecznie gdyby prawdą okazało się, że Hyper-V potrafi osiągnąć pełną moc serwera na maszynie wirtualnej tylko z jednym wirtualnym procesorem, byłby to hit i znaczna oszczędność na licencjach (nie tylko na aplikacje per procesor, ale także na systemy - na przykład Windows Server 2008 Standard obsługuje tylko cztery procesory i nawet jak przypiszemy mu więcej, to ich nie zobaczy).

Maszyna testowa to znany z naszych poprzednich testów hypervisorów serwer Intela z dwoma czterordzeniowymi procesorami Xeon 5405. Metodologia testów: Hyper-V 2008 R2, na nim jedna maszyna wirtualna z Windows Server 2008 Enterprise x64, różna liczba procesorów wirtualnych. W przeciwieństwie do konkurencyjnych hypervisorów Hyper-V nie oferuje zbyt wielu opcji konfiguracyjnych dla procesorów, więc test jest w zasadzie prosty. Aplikacją pomiarową była Sandra 14 w wersji inżynierskiej. Czy będzie różnica w wydajności?

Tak jak się spodziewałem, wyniki mówią same za siebie - jednak warto przypisywać więcej wirtualnych procesorów do maszyny wirtualnej, jeden procesor wirtualny niewiele potrafi. Prawdą jest, że Hyper-V rozrzuca wątki z procesorów wirtualnych na wszystkie posiadane procesory fizyczne (nie da się tego ograniczyć, tak jak np. w ESX/ESXi), ale nieprawdą jest, że potrafi agregować wydajność kilku procesorów w jednym wirtualnym. Nie rozwiązuje to więc problemu z licencjonowaniem - jeśli chcemy wydajnych aplikacji, musimy przypisać więcej procesorów do maszyny wirtualnej, za co musimy więcej zapłacić.

Skoro rozstrzygnęliśmy już kwestię Hyper-V, weźmy teraz na tapetę ESXi i jego bardzo ciekawą, nieodkrytą przeze mnie wcześniej możliwość przypisania większej niż jeden liczby rdzeni per procesor wirtualny. Może to i wstyd przyznać, ale do tej pory nie wiedziałem, że - jak wspomniał w komentarzach jeden z naszych czytelników, Webio - istnieje eksperymentalny parametr, który pozwala przypisać do jednego wirtualnego procesora więcej rdzeni niż jeden. Standardowo każdy wirtualny procesor widziany jest bowiem jako oddzielny procesor "fizyczny" przez system gościa. Dzięki omawianemu parametrowi można doprowadzić do sytuacji, gdzie wirtualny system widzi tylko jeden procesor "fizyczny", ale za to cztery lub nawet osiem procesorów logicznych - jako wirtualne rdzenie. Niweluje to sporo poważnych ograniczeń - pomijając kwestie oszczędności w licencjonowaniu per procesor, dzięki ustawieniu dwóch rdzeni na vCPU możliwe jest na przykład wykorzystanie ośmiu wirtualnych procesorów w Windows Server 2008 Standard o czym wspominałem już wyżej.

Parametr, o którym mowa to cpuid.coresPerSocket i należy wprowadzić go w ustawieniach maszyny wirtualnej w oknie Configuration Parameters, które to z kolei trzeba wywołać z karty Options właściwości maszyny wirtualnej (sekcja Advanced - General). Wartością tego parametru jest liczba rdzeni per procesor wirtualny - musi być to dzielnik liczby wirtualnych procesorów przypisanych do maszyny. Przykładowo mając cztery wirtualne procesory możemy ustawić 1 (domyślne), 2 lub 4 rdzenie. Spowoduje to, że liczba widzianych przez system procesorów "fizycznych" będzie wynosić odpowiednio 4, 2 i 1.

Zanim przejdę do wyników testów, muszę przyznać, że srogo zawiodłem się na bezpłatnym ESXi. Zawód, a wpierw zdziwienie nadeszło, gdy spróbowałem przypisać osiem wirtualnych procesorów (a właściwie cztery po dwa rdzenie) do jednej z testowych maszyn wirtualnych - w momencie startu maszyny ESXi poinformował mnie, że nie mam odpowiedniej licencji... Może to i wstyd (kolejny już raz dzisiaj), ale VMware tak trąbiło o wsparciu dla 8-way SMP (a XenServer też ma to od jakiegoś już czasu), że jakoś nie doczytałem, że w przypadku ESXi funkcjonuje to jedynie po zakupieniu licencji vSphere Enterprise Plus. Jest to moim zdaniem spory mankament, choć z drugiej strony wydany kilka dni temu hypervisor Microsoftu w wersji R2 również nie pozwala przypisać więcej niż czterech wirtualnych procesorów. Dlaczego jednak mamy równać w dół?

Wracając do meritum - parametr sterujący liczbą rdzeni może i eksperymentalny, ale nie byłbym sobą, gdybym nie sprawdził jak takie wirtualne rdzenie mają się do wydajności "zwykłych" wirtualnych procesorów. Tym razem testy przeprowadziłem na aktualnie testowanym u nas w redakcji (pod różnym kątem - szczegóły wkrótce) serwerze Triline opartym o komponenty Intela z gorącymi nowinkami, takimi jak dwa procesory Intel Xeon serii 5560 (Nehalem) czy dyski SSD. Zainstalowałem ESXi 4.0 (licencja trial, żeby sprawdzić też ośmioprocesorowy wariant) i posadziłem na nim jedną maszynę wirtualną z Windows Server 2008 Enterprise x64 po kolei przypisując różne ilości procesorów i rdzeni. Oto wyniki z Sandry:

Uwzględniając drobny margines błędu można śmiało powiedzieć, że wydajność konfiguracji opartych o tę samą liczbę wirtualnych procesorów - bez względu na ilość rdzeni per procesor - nie różni się. Rzeczywiście więc rozwiązuje to poruszany przeze mnie w ostatnim wpisie temat drogich licencji per procesor w środowiskach wirtualnych - możemy zmniejszyć liczbę procesorów, a jednocześnie zachować ich wydajność. Całkowitą euforię powstrzymuje jedynie fakt, że jak udało mi się ustalić, magiczny parametr jest już obecny w ESX od kilku aktualizacji i skoro nadal pozostaje eksperymentalny, to może nie należy rzucać się na niego bez co najmniej głębszego zastanowienia... Co ciekawe, podobna opcja dostępna jest także w XenServerze - opisuje to chociażby ten wątek na forum Citriksa. Niestety w przeciwieństwie do ESXi, bezpłatny XenServer nie pozwala na jej zastosowanie, trzeba zaopatrzyć się w płatne narzędzia. Również tam jednak opcja ta jest oficjalnie nieudokumentowana - wniosek z tego taki, że wirtualizacja wielordzeniowych procesorów pozostaje póki co w sferze eksperymentów.

Licencjonowanie to zawsze gorący temat, a w przypadku niektórych producentów – takich jak na przykład Microsoft – często mocno skomplikowany. Jednym z zastanawiających scenariuszy jest licencjonowanie per procesor w środowiskach wirtualnych. Procesory fizyczne, logiczne, wirtualne – jak to wszystko ugryźć? Podjęliśmy starania, by u źródła wyjaśnić istotę problemu i znaleźć odpowiedzi na wszystkie nurtujące pytania.

Na początek przedstawmy potencjalne problemy z interpretacją zapisów licencyjnych, na jakie można natrafić w środowiskach wirtualnych. Pierwszy scenariusz to jednoprocesorowy serwer z czterema rdzeniami (procesorami logicznymi), na którym pracuje Windows Server 2008 Standard z rolą Hyper-V. Generalnie nie ma to dla nas znaczenia, jaki system pracuje na partycji fizycznej – interesuje nas tylko temat partycji wirtualnych. Serwer ten hostuje jedną maszynę wirtualną z czterema wirtualnymi procesorami, na której pracuje SQL Server 2008 licencjonowany per procesor. Ile licencji na serwer bazodanowy potrzebujemy? Wariant tego scenariusza – dwie maszyny wirtualne z dwoma lub czterema (wtedy mamy do czynienia z overcommitmentem) wirtualnymi procesorami i dwoma SQL Serverami.

Drugi problem dotyczy dwuprocesorowej maszyny i identycznego układu maszyn z SQL Serverami. Powstaje pytanie, czy fizyczne procesory mają w jakikolwiek sposób przełożenie na procesory wirtualne? W niektórych hypervisorach, np. w ESXi 4.0 mamy możliwość przypisania danego procesora fizycznego tylko do konkretnej maszyny wirtualnej, w Hyper-V takiej możliwości już nie ma. Oznacza to, że nawet maszyna wirtualna z jednym wirtualnym procesorem może korzystać z obu procesorów fizycznych. Ile zatem licencji per procesor dla SQL Servera potrzebujemy?

Z braku jednoznacznych informacji na stronach Microsoftu zapytaliśmy u źródła, jak powinno się rozumieć niektóre zapisy licencyjne. Rozwiązania obu problemów szczęśliwie udało się podać jednocześnie, choć mogą być nieco zadziwiające – w kwestii licencjonowania produktów Microsoftu per procesor (np. SQL Servera) pod uwagę brane są jedynie procesory bezpośrednio obecne w systemie, w którym pracuje instancja licencjonowanego produktu. Mówiąc jaśniej, na maszynie wirtualnej interesują nas jedynie procesory wirtualne i nie zastanawiamy się nad tym, ile procesorów fizycznych jest „pod spodem”. Niestety w praktyce oznacza to, że nawet na serwerze jednoprocesorowym potrzebujemy czterech licencji per procesor, jeśli przydzielimy maszynie wirtualnej cztery wirtualne procesory... Co więcej, gdy dodamy drugą maszynę wirtualną – na przykład także z czterema wirtualnymi procesorami (overcommitment) – to SQL Server zainstalowany na takiej maszynie wymaga kolejnych czterech licencji per procesor. Jeśli dodatkowo na partycji fizycznej pracuje trzecia instancja produktu, ona również wymaga własnej licencji na procesor - w przypadku jednoprocesorowej maszyny już tylko jednej. W scenariuszu ilustrowanym przez poniższy schemat potrzebowalibyśmy więc sześciu licencji per procesor.

Rozwiązaniem tego dosyć drogiego problemu są, niestety także dość drogie, licencje per procesor na edycje Enterprise serwerów SQL Server 2005 i 2008. Posiadają one specjalny zapis, który po przypisaniu licencji na każdy procesor fizyczny serwera-hosta pozwala na pracę dowolnej liczby instancji na tym serwerze, włączając w to instancje fizyczne oraz wirtualne. W przypadku, gdy mamy więcej maszyn wirtualnych z SQL Serverem na jednym serwerze fizycznym, licencja Enterprise może okazać się tańsza niż zakup kilku licencji per procesor w edycji Standard. Na przykład w tym samym scenariuszu (obrazek powyżej) zamiast sześciu licencji per procesor wystarczą dwie, ale Enterprise.

Przy okazji przypomnijmy jeszcze, jak wygląda kwestia licencjonowania wirtualnych instancji systemów Windows Server 2008. Edycja Standard pozwala na uruchomienie jednej fizycznej i dodatkowo jednej wirtualnej instancji systemu. Edycja Enterprise rozszerza tę możliwość do czterech wirtualnych instancji systemu, zaś edycja Datacenter nie posiada żadnych ograniczeń co do uruchamiania dodatkowych wirtualnych instancji. Należy jednak pamiętać, że istnieje zapis w licencji stanowiący wyraźnie, że instancja fizyczna może być wykorzystywana jedynie do hostowania i zarządzania instancjami wirtualnymi. Możemy więc posadzić na niej Hyper-V i administrować maszynami wirtualnymi, ale zgodnie z licencją nie możemy na niej skonfigurować serwera IIS i hostować na nim firmowej witryny WWW czy wewnętrznego SharePointa.

Abstrahując od momentami dość absurdalnych rozwiązań, temat licencjonowania per procesor w środowiskach wirtualnych jest ciekawy. Warto jednak najpierw zastanowić się, czy wirtualizacja SQL Servera jest aby na pewno konieczna – nawet w średniej wielkości środowiskach koszty licencjonowania per procesor mogą być wyższe, niż zakup dedykowanego i prawdopodobnie wydajniejszego niż maszyna wirtualna sprzętu do obsługi baz danych. Ostatecznie nawet Microsoft w szumnie reklamowanej migracji serwisu internetowego TechNet na Hyper-V zdecydował się na wirtualizację wszystkiego oprócz SQL Serverów...

Jeśli nurtują Was podobne pytania odnośnie licencjonowania w niekonwencjonalnych scenariuszach, dajcie znać - być może uda nam się sprawę wyjaśnić i opisać.

Wydaje się, że niechęć pewnego dużego producenta sprzętu serwerowego do Opery kosztowała go kilka milionów norweskich koron. Technicznie rzecz biorąc nie był to koszt, a jedynie brak potencjalnego dochodu. Mimo wszystko cała sytuacja jest całkiem zabawna i zdecydowanie warta wzmianki w naszym serwisie.

Opera przewidując szybki rozwój swoich usług postanowiła rozbudować centrum danych. Jak informuje na swoim blogu jeden z programistów, Hallvord R. M. Steen, nie chodziło o kilka maszyn - w grę wchodziło naprawdę spore zamówienie. Nic więc dziwnego, że do norweskiej firmy szybko zaczęły spływać oferty od największych producentów serwerów na świecie, a razem z ofertami - także egzemplarze testowe.

Duży budżet na nowy sprzęt, wcześniej serwery do zabawy - gratka dla admnistratorów. Administratorzy jednak, jak przystało na oddanych pracowników firmy, korzystali oczywiście z przeglądarek Opera. Tutaj zabawa niestety się kończy, a konkretniej mówiąc w momencie wejścia do interfejsu zdalnego zarządzania serwerów pewnego dużego producenta (nazwy Steen niestety nie ujawnia, ale mówi, że wszyscy mamy spore szanse używania jego sprzętu).

Owy interfejs do zdalnego zarządzania wyrzucał niestety pod Operą jedynie stronę z informacją o błędzie. Nie było możliwości pracy pod tą przeglądarką. Administratorzy, jak to administratorzy, wykazali się należytą dociekliwością i zajrzeli do kodu strony. Spotkała ich tam bardzo interesująca niespodzianka - cztery wiersze kodu JavaScript:

if (is.opera)
{
   window.location.href="config/error.htm";
}

Dalszy komentarz jest już chyba zbędny... Dodajmy tylko, że użytkownicy, jak to użytkownicy - jeszcze bardziej dociekliwi od adminów, ustalili w komentarzach na blogu, że może chodzić o serwery firmy Dell. Nie jest to jednak do końca potwierdzone - nie mamy akurat pod ręką żadnej maszyny tej firmy, by to sprawdzić. Interfejs RMM3 Intela nie ma w każdym razie z Operą żadnych problemów ;-)

Swoją drogą, szkoda, że Opera tak powierzchownie oceniła walory serwerów tego producenta - może należało jednak odpalić Internet Explorera i dać serwerom szanse wykazania się? :-)

Z poradą, która zaleca ustawienie parametru NUMPROC w konfiguracji bootowania systemu Windows tak, by "spowodować wykorzystanie wszystkich procesorów podczas uruchamiania" i w ten sposób cały ten proces przyspieszyć spotkałem się już wielokrotnie. Gdy zobaczyłem ją dzisiaj ponownie opublikowaną przez jednego z polskich blogerów IT pomyślałem, że tak dłużej już być nie może - czas wreszcie, by ktoś wyjaśnił, do czego naprawdę służy ta opcja i dlaczego nie ma nic wspólnego z przyspieszaniem bootowania.

Na początek wyjaśnienie, o co konkretnie chodzi: są osoby, które twierdzą, że system Windows Vista i Windows 7 podczas bootowania na komputerach wielordzeniowych wykorzystuje tylko jeden procesor logiczny. W związku z tym faktem wydajność bootowania rzekomo ma być obniżona. Szczęśliwie dla osób wierzących w opisywany tutaj mit istnieje rozwiązanie tego problemu - wystarczy udać się do narzędzia msconfig i ustawić parametr NUMPROC (znany też jako "Liczba procesorów" w Zaawansowanych opcjach na zakładce Rozruch) na liczbę odpowiadającą ilości posiadanych przez nas procesorów logicznych. Jak mamy dwurdzeniowy procesor, zaznaczamy więc tę kratkę i ustawiamy tam dwa procesory. Jasne jak słońce.

Jeśli chcecie dobrej rozrywki, powiedzcie komuś o tym "problemie" i jego cudowym "rozwiązaniu", po czym obserwujcie, jak sam przyzna Wam rację i zauważy, że różnica jest odczuwalna, a system bootuje o jakieś 30% szybciej! Jeśli nie chcecie zgrywać się ze znajomych, wystarczy poczytać komentarze do powyższych porad, od których roi się w Internecie polskim i światowym. W końcu nie bez powodu w medycynie już od dawna funkcjonuje placebo - mimo tego, że jego skuteczność trudno uzasadnić medycznie, to jednak w pewnych sytuacjach przynosi pożądane efekty. Tak samo jest z tym parametrem.

Parametr NUMPROC został udostępniony w menedżerze rozruchu systemu Windows jeszcze na długo przed pojawieniem się wielordzeniowych procesorów. Służy wyłącznie do celów diagnostycznych lub testowych. Za jego pomocą można ograniczyć liczbę procesorów wykorzystywanych przez system - nie tylko podczas startu, ale przede wszystkim w trakcie pracy. Dzięki temu można np. testować wady procesorów (przydatny jest tu też inny parametr ONECPU, który to z kolei sprawia, że system wykorzystuje tylko pierwszy procesor). Ustawienie tego parametru na liczbę równą ilości procesorów zainstalowanych w systemie spowoduje, że system będzie korzystał ze wszystkich procesorów - dokładnie tak, jak bez tego parametru... Nie ma w tym nic dziwnego, pozostałe parametry rozruchu pozwalają między innymi w analogiczny sposób ograniczać pamięć RAM - starsze systemy nie uruchamiają się z dzisiejszymi gigabajtami pamięci i trzeba im ją ograniczać właśnie w pliku boot.ini. Również ustawienie ograniczenia ilości pamięci RAM na zainstalowaną w systemie ilość nie spowoduje, że komputer będzie działać szybciej. W szczególności nie spowoduje też, że z 2 GB zrobi się 4 GB.

Mit mitem, ale wykorzystywanie przez system tylko jednego procesora podczas rozruchu jest akurat w tej historii faktem, choć nie na taką skalę jak twierdzą orędownicy cudownej porady - można o tym przeczytać chociażby w książce Windows Internals Marka Russinovicha, której fragment opublikowany jest w artykule serwisu Within Windows obalającym mit parametru NUMPROC. Wynika z niego, że podczas rozruchu najpierw inicjowane są przerwania sprzętowe, następnie ładowany jest sterownik graficzny używany do wyświetlania ekranu bootowania, później inicjowane są funkcje zarządzania energią i czas systemowy. Dopiero wtedy uruchamiany jest drugi i kolejne procesory. Nie jestem jednak specjalnie przekonany, czy procesory te byłyby w stanie znacząco wpłynąć na czas wykonania jakże absorbujących procesor czynności takich jak załadowanie sterownika do wyświetlenia loga Windows czy uruchomienie zegara.

Nie ma więc żadnego przyspieszania bootowania za darmo. Czy nie byłoby dziwne, że Microsoft domyślnie ograniczałby wykorzystanie procesorów i tym samym opóźniał bootowanie - proces, o którego przyspieszenie zabiega się przy każdej kolejnej edycji Windows, po czym okazuje się, że nadal jest zdecydowanie zbyt wolny? Czas wrócić do rzeczywistości. W IT nie ma miejsca na magiczne sztuczki.

Miałem niedawno okazję po dłuższej przerwie stawiać nieskomplikowaną witrynę sharepointową i przypomniałem sobie o pewnym mitycznym już wręcz problemie, o którym powinien wiedzieć każdy polski administrator SharePointa. Sprawa jest generalnie bardzo prosta, znana od lat i dobrze opisana w Internecie - uniemożliwia wpisanie słowa "łoś" w kontrolce do tekstu sformatowanego.

Mówiąc ściśle, w kontrolce tej niemożliwe jest wpisanie polskich znaków "ś" oraz "ł". Jest to spowodowane tym, że domyślnie SharePoint przechwytuje kombinacje klawiszy ALT-L i ALT-S w trakcie edycji tekstu i traktuje je jako skróty klawiaturowe. W efekcie by napisać wspomnianego "łosia" trzeba posłużyć się dwoma innymi skrótami klawiaturowymi: CTRL-C i CTRL-V, wklejając do SharePointa tekst napisany poprawną polszczyzną w Notatniku, który szczęśliwie z polskimi znakami jakoś sobie radzi.

Prawda, że śmieszne? Jeszcze śmieśniejsze jest jednak to, że aktualnie jest to jedyna działająca metoda pozbycia się tego problemu według Microsoftu. Od premiery Windows SharePoint Services 3.0 i Office SharePoint Server 2007 minęły już prawie trzy lata. Mniej więcej pół roku po premierze na blogu Cezarego Aniśko zajmującego się w polskim oddziale Microsoftu między innymi SharePointem pojawił się wpis dotyczący poprawek, które rozwiązywały ten problem. Poprawki oznaczone numerem KB940405 oraz KB940406 miały być panaceum na "łosia". Co prawda Microsoft zarzekał się, że są one już gotowe i czekają na pobranie, ale ponieważ tekst artykułu do Bazy Wiedzy jeszcze nie powstał, to poprawki nie były dostępne publicznie i trzeba było ich zażądać za pomocą dostępnego jeszcze wówczas formularza on-line.

Wszystko pięknie - sam pamiętam, jak dopytywałem co kilka tygodni znajomych w Microsofcie, kiedy te poprawki w końcu wyjdą bardziej publicznie. Nie pamiętam już, na czym sprawa stanęła - najprawdopodobniej znudziło mi się dopytywanie. Problem nie był też jakoś specjalnie palący, bo w sieci krążyły nieoficjalne sposoby na ominięcie problemu (których zastosowanie skutkowało jednak utratą supportu).

Minęło kilkanaście miesięcy, doczekaliśmy się drugiego Service Packa do SharePointa i po drodze kilku innych poprawek, ale Baza Wiedzy Microsoftu na hasło "KB940405" albo "KB940406" nadal milczy. Sprawa wygląda tym bardziej kiepsko, że o ile kiedyś faktycznie można było zażądać on-line wspomnianych poprawek, tak teraz Microsoft z formularza zrezygnował na rzecz specjalnego przycisku umieszczonego bezpośrednio na poszczególnych stronach KB. Sęk w tym, że w przypadku tych dwóch feralnych poprawek strony KB nie istnieją, więc i w przycisk trudno kliknąć... Również telefonicznie nie udało mi się poprawek uzyskać - pani poinformowała mnie, że takie łatki nie istnieją. Próbowałem w związku z tym skorzystać nawet z usługi Online Concierge dla subskrybentów TechNetu, ale po wpisaniu pytania w pole tekstowe otrzymałem tylko komunikat walidatora, że powinienem przed wysłaniem wpisać pytanie w pole tekstowe... I to zarówno pod Internet Explorerem 8, jak i Firefoksem 3.5.

W międzyczasie natknąłem się na rzekome rozwiązanie (a raczej obejście problemu) zaimplementowane w Service Packu 1 dla WSS 3.0. Mianowicie chodzi o polecenie stsadm.exe -o setproperty -url http://adreswitryny -pn "richtexteditorshortcutenabled" -pv "no", które jednak niestety u mnie nie wiedzieć czemu nie działa. Ostatecznie więc dzisiaj, podobnie jak za każdym razem wczesniej wdrażając witryny sharepointowe skończyłem na niekoszernej edycji plików i utracie wsparcia technicznego. Pocieszam się jednak, że jak widać wsparcie to w przypadku SharePointa i tak na niewiele się przydaje...

Nie ma lepszej nagrody za beta-testy jakiegoś produktu niż satysfakcja z bezpośredniej pracy z grupą produktową zwieńczonej poprawieniem istniejącego od lat, uciążliwego błędu. Niniejszym chciałem się właśnie pochwalić, że taki uciążliwy błąd w kliencie VPN systemu Windows 7 udało mi się zgłosić i doprowadzić do rozwiązania. Jeśli w swojej sieci korzystacie ze split-tunnelingu, czytajcie dalej... :-)

Na początek trochę teorii. Łącząc się zdalnie do sieci firmowej na ogół jest tak, że tunel VPN staje się jedynym oknem na świat klienta - dzięki temu administrator zyskuje pełną kontrolę nad komputerem, gdy tylko jest obecny w sieci firmowej. Jak to często jednak bywa, bezpieczeństwo zwykle nie idzie w parze z komfortem pracy. Konieczność przepychania calego ruchu przez tunel VPN, zwłaszcza w "luźniejszych" środowiskach jest wielce problematyczna.

Dla takich scenariuszy wymyślono split-tunneling, czyli możliwość przesyłania przez tunel VPN jedynie tego ruchu, który adresowany jest bezpośrednio do sieci firmowej. Cała reszta przesyłana jest istniejącym łączem internetowym klienta z pominięciem VPN. Aby to działało, w większości przypadków konieczne jest posiadanie przez klienta VPN odpowiednich tras do sieci zdalnej. Klient takie trasy może dodać sobie samodzielnie po zestawieniu tunelu, ale znacznie prościej jest je wysłać automatycznie przy pomocy DHCP. Dla porządku powiem tylko, że częściowym rozwiązaniem jest także stworzenie klientom profilu połączenia narzędziem CMAK - w moim przypadku to jednak nie wchodziło w grę.

Skonfigurowany lata temu kombajn Routing and Remote Access + serwer DHCP z przypisaną opcją 121 (classless static routes) spisywał się znakomicie przez długi czas - do momentu, gdy u klientów VPN pojawił się Windows Vista. Wtedy wszystko przestało działać, bo trasy w ogóle nie były dodawane. Eskalacja tego problemu w pomocy technicznej Microsoftu doprowadziła do wydania artykułu Bazy Wiedzy KB933340, a później także poprawki, która została nawet umieszczona w Service Packu 1. Faktycznie poprawka coś tam poprawiała, bo trasy były już pomyślnie dodawane do tablicy routingu klienta po ustanowieniu połączenia. Problem jednak w tym, że raz na kilka połączeń nawet wspomniana poprawka nie mogła rozwiązać tego coraz bardziej uciążliwego problemu - tras nie było.

Po kilkunastu miesiącach wielokrotnego rozłączania i ponownego łączenia pojawiła się wersja beta systemu Windows 7. Z dużym zainteresowaniem sprawdziłem, czy Microsoftowi udało się uporać z problemem. Niestety z przerażeniem stwierdziłem, że jest jeszcze gorzej - jeśli w Viście SP1 trasy z DHCP były brane pod uwagę w trzech przypadkach na pięć, tak w Windows 7 w najlepszym razie w jednym na pięć. Korzystając z faktu, że jestem beta-testerem w technicznym programie beta Windows 7 zgłosiłem to zachowanie jako błąd.

Poprosiłem o walidację błędu na grupach dyskusyjnych i wśród znajomych beta-testerów. Poświęciłem nawet kilka chwil na zbudowanie kompletnego środowiska testowego złożonego z Windows Server 2008, Windows Vista i Windows 7, na którym skonfigurowałem RRAS, DHCP i klientów VPN. Okazało się, że problem jest powtarzalny za każdym razem na czystych instalacjach systemów. Wywołało to oczekiwane przeze mnie zainteresowanie Microsoftu. W trakcie rozmów z inżynierem odpowiadającym za moje zgłoszenie wysłałem mnóstwo logów i raportów z narzędzi diagnostycznych.

Opłacało się jednak - błąd został rozwiązany w jednym z ostatnich buildów Windows 7! Każde połączenie skutkuje prawidłowym zaaplikowaniem tras u klienta VPN. Nie ma już problemów ze split-tunnelingiem i nie trzeba łączyć się po kilka razy, zanim VPN będzie funkcjonować prawidłowo. Szkoda tylko, że trwało to trzy lata. Szkoda też, że prawdopodobnie nie doczekamy się podobnej poprawki dla Windows Vista - Service Pack 2 nadal zawiera wspominany błąd, a po moim pytaniu o dostępność oddzielnej łatki niestety Microsoft zamilkł...

Na szczęście nie używam już Visty... ale będę o tym pamiętał w programie beta trzeciego Service Packa! :-)