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! :-)

Z wielką pompą światło dzienne ujrzał VMware vSphere, a wraz z nim między innymi nowa wersja bezpłatnego hypervisora ESXi 4. Właśnie kilka takich serwerów pracujących na do niedawna najnowszej wersji ESXi 3.5 Update 4 posiadamy w swojej infrastrukturze. Bardzo dobre wyniki testów wydajnościowych skłoniły nas do bliższego zainteresowania się tematem migracji do wersji 4. Trzeba było jednak podjąć decyzję - czy instalować wszystkie hosty od nowa i tym samym odbudowywać konfigurację praktycznie od zera, czy też skrócić sobie drogę i skorzystać z oficjalnie dostępnej ścieżki uaktualnienia "w miejscu".

Pomimo tego, że słyszałem wiele zastanawiająco stanowczych opinii odradzających takie uaktualnienia w przypadku głównych wydań zmieniających cyfrę przed kropką, to mimo wszystko perspektywa rekonfiguracji kilku maszyn nie była wesoła. Zdecydowaliśmy więc, że poświęcimy jedną z najmniej istotnych maszyn i sprawdzimy, jak takie uaktualnienie wygląda, jakich spodziewać się problemów i na co zwrócić uwagę. Ostatecznie upgrade jest oficjalnie wspierany przez producenta, aż taki pesymizm jest tu więc chyba nieuzasadniony.

Już na samym początku było "pod górkę". Okazało się, że jeśli nie posiadamy płatnego vCenter, to uaktualnienia hostów do wersji 4 może dokonać tylko narzędzie Host Update Utility będące częścią vSphere Clienta z najnowszej wersji. Pomimo tego jednak, że oficjalny przewodnik upgrade'u liczy aż 112 stron, nie doszukamy się w nim informacji w jaki sposób owy Host Update Utility zainstalować. No, może poza wskazówką, że można go pobrać ze strony WWW hosta - oczywiście po uaktualnieniu. To co było pierwsze - jajko czy kura? VMware chyba jakoś nie potrafiło się zdecydować i postanowiło pozostawić te rozważania administratorom.

Szczęśliwie miałem pod ręką testową maszynę - tę samą, na której Tomek przeprowadzał testy wydajnościowe - i stamtąd pobrałem instalator vSphere Clienta. Później trafiłem też na artykuł, który może pomóc osobom nie dysponującym wolnym sprzętem. Opisuje on, jak wyodrębnić sam instalator vSphere Clienta z paczki aktualizacyjnej. Przy okazji jest tam też dość lakoniczna instrukcja aktualizacji, która jednak - jak się przekonałem - jest mało przydatna. Nie uprzedzajmy jednak faktów.

Mając już instalator chętnie przystąpiłbym do aktualizacji. Niestety na drodze stanął kolejny problem - vSphere Client nie działa na Windows 7. Trochę to dziwne, ale rozumiem - beta to beta, nie można wymagać od VMware wspierania przedpremierowych wersji Windows. Zainstalowałem jakąś maszynę wirtualną z Vistą na notebooku i tam odpaliłem vSphere Clienta. So far so good.

Tak jak przypuszczałem, przed procesem uaktualnienia host musi być wprowadzony w Maintenance mode. Nie przypuszczałem jednak, że aby to zrobić, będę musiał zainstalować starą wersję VMware Infrastructure Clienta - czyli bezpośredniego poprzednika vSphere Clienta. Nowa wersja bez pomocy starej nie poradzi sobie z podłączeniem do ESXi 3.5. Nie powiem, że byłem na tym etapie jakoś specjalnie rozżalony, ale cała ta aktualizacja zwyczajnie już mnie irytowała. Najlepsze było jednak to, że po instalacji starej wersji VI Clienta, przejścia do Maintenance mode i uruchomienia aktualizacji okazało się, że żadnej aktualizacji nie będzie.

The boot device layout on the host does not support upgrade. Ale o co konkretnie chodzi? Tego już niestety instalator nie napisał. Nie przypominam sobie też, by konfiguracja hosta była jakoś specjalnie wyszukana. Poszukiwania w Googlu naprowadziły mnie jedynie na trop związany ze zbyt małą ilością wolnego miejsca na partycji boot ESXi - powodem miała być poprzednia wersja hypevisora zapisana w razie konieczności cofnięcia po wcześniejszej drobnej aktualizacji. Inny forumowicz twierdził, że ESXi 4 wymaga dwa razy większej partycji boot niż wersja 3.5 i po prostu o ile sami nie przygotowaliśmy wcześniej odpowiednio dużej partycji, to teraz aktualizacja nie powiedzie się.

Jakoś nie chciało mi się w to wszystko wierzyć, więc wziąłem nasz testowy serwer - o sprzęcie innym niż maszyna z pierwszego podejścia - i posadziłem tam najnowszy ESXi 3.5 (bez żadnych zajmujących miejsce poprzednich wersji), a potem powtórzyłem wszystko próbując go zaktualizować. Niestety błąd również się powtórzył - na czystej, domyślnej instalacji (w gruncie rzeczy nie da się tam w instalatorze zbyt wiele zmienić) z czystym datastorem i bez maszyn wirtualnych.

Problem opisałem na forum VMware, ale niestety nikt nic konkretnego tam jeszcze nie napisał. Już wczoraj czytałem o problemach z aktualizacją na serwerach Della, ale nasze maszyny nie są ich produkcji. Wszystko wskazuje więc na to, że raczej niewiele osób będzie miało szansę przeprowadzić pomyślne uaktualnienie. Jeśli jednak komukolwiek się udało, chętnie z nim porozmawiam :-)

29 kwietnia Microsoft poinformował o uzyskaniu statusu RTM przez Service Pack 2 dla Windows Viata i Windows Server 2008. Minął już prawie miesiąc, a dodatku w centrum pobierania nie widać. Microsoft zapytany o powód opóźnienia mówi, że nie ma żadnego opóźnienia, bo SP2 był od zawsze planowany na drugi kwartał 2009 roku, a ten się przecież jeszcze nie skończył. Ale zaraz, zaraz... czy tego filmu już przypadkiem nie widzieliśmy?

Trudno się oprzeć takiemu wrażeniu - sytuacja wygląda niemal identycznie, jak przed rokiem, gdy Microsoft wydawał chyba jeszcze bardziej oczekiwany dodatek Service Pack 1 dla Windows Vista. Premiera wersji RTM miała miejsce 4 lutego 2008, a w centrum pobierania i Windows Update dodatek pojawił się dopiero po ponad 5 tygodniach - 18 marca. Dlaczego trwało to tak długo? Microsoft tłumaczył, że powstał problem z niektórymi sterownikami, dlatego firma wolała wstrzymać się z publikacją SP1 na masową skalę do momentu rozwiązania sprawy. Pomimo sporego opóźnienia wszystko to wydaje się jednak całkiem sensowne.

Teraz przy okazji Service Packa 2 dla Windows Vista i Windows Server 2008 mamy powtórkę z rozrywki - wersja RTM ukończona 29 kwietnia, dzień później otrzymali ją nawet beta-testerzy i posiadacze płatnych subskrypcji TechNet i MSDN. Niestety na tym koniec - i jest nawet gorzej, niż poprzednio, bo tym razem razem nie ma żadnego wytłumaczenia ani nawet przybliżonej informacji o dacie wydania SP2. Korporacja zapytana przez Mary Jo Foley odpowiada ze stoickim spokojem, że nie ma żadnego opóźnienia - przecież od razu była mowa o "drugim kwartale 2009 roku", a ten się jeszcze nie skończył. No cóż, trudno odmówić racji, ale nie takiej odpowiedzi moglibyśmy sobie życzyć.

Na blogach, serwisach informacyjnych czy forach z całego świata nie słychać o żadnych problemach z Service Packiem 2 - dlaczego więc coś, co jest już ukończonym i przetestowanym produktem nie może zostać wydane publiczne dla wszystkich? Czy odwlekanie z niewiadomych powodów premiery gotowych Service Packów będzie już dziwną tradycją? Na te pytania niestety chyba nikt nigdy już nie udzieli odpowiedzi...

Kiedyś pisałem tutaj, jak duży - moim zdaniem - błąd popełnił Microsoft, gdy w Windows Server 2008 usługa backupu pozbawiona była możliwości tworzenia kopii zapasowej on-line danych serwera Exchange. Nawet ci, którzy nie administrowali nigdy Exchange, ale robili choć raz kopię zapasową w Windows Server 2008 wiedzą, że pomimo ciekawego, nowego formatu VHD jako nośnika kopii to jednak do narzędzia ntbackup nowa usługa backupu się nie umywa. Mocno ograniczona, mało opcji, wszystko trzeba robić w jedyny słuszny "Microsoft-way".

Jedyną opcją zabezpieczenia serwera Exchange był więc backup offline - rozwiązanie raczej mało przyjemne - lub zakup oddzielnego Data Protection Manager, który umożliwiał to, co niegdyś za darmo (no, w ramach licencji na Windows Server) oferował ntbackup. Microsoft twierdził, że "tak jest lepiej". Ewentualnie można było nagiąć trochę umowę licencyjną (choć tak naprawdę nie jestem pewien, czy to rzeczywiście naruszało licencję?) i przenieść sobie kilka bibliotek dll ze starego systemu Windows Server 2003, by uruchomić ntbackup na nowym.

Z dużym zadowoleniem i ulgą przyjąłem teraz informację, że Exchange 2007 SP2 wzbogacony zostanie o plugin do narzędzia Windows Server Backup umożliwiający przeprowadzania backupu online. Nie da się co prawda zrobić, tak jak w ntbackup, jedynie backupu magazynu Exchange, ale przynajmniej magazyn zostanie zbackupowany podczas backupu całego dysku i prawidłowo wyczyszczone zostaną logi. Przy odzyskiwaniu można natomiast wybrać tylko odzyskanie magazynu Exchange. Trudno się nie zgodzić, że to duży "postęp" (tzn. jest _prawie_ tak, jak było wcześniej).

Dlaczego przyjąłem tę wiadomość z zadowoleniem? Cóż, okazało się że moje marudzenie nie było nieuzasadnione, co zresztą potwierdzały rzesze innych użytkowników. Dlaczego z ulgą? Bo to znamienny sygnał, że cokolwiek Microsoft nie zrobi, bez znaczenia jak bardzo będzie się upierał przy swoim, to jest szansa, że ostatecznie siła użytkowników przechyli szalę i zmusi firmę do powrotu do poprzednich, ewidentnie lepszych rozwiązań. Mówię o tym w kontekście zarówno rzeczy istotnych (na przykład nie zdziwiłbym się, gdyby w kolejnych wersjach Windows pojawiło się z powrotem ulepszone narzędzie ntbackup) ale także w kontekście rzeczy bardziej przyziemnych, choć symbolicznych (w Windows Vista mieliśmy problem ze zmianą rozdzielczości, w Windows 7 zmiana rozdzielczności została wysunięta z powrotem do menu kontekstowego pulpitu, a kto wie, może w Windows 8 wrócą stare Właściwości ekranu?).