Artykuły

A A A
Drukuj Ekportuj do PDF
Opublikowane: 2009.04.24 12:00 | Paweł Damian | Aktualizacja: 2009.04.24 12:16

Jak zmigrowaliśmy portal WSS.pl

Portal wss.pl przeszedł ostatnio wiele zmian. Część z nich była łatwo zauważalna i polegała na dodaniu nowych funkcjonalności lub usunięciu niedociągnięć. Sporo prac odbyło się jednak w sposób zupełnie dla czytelników wss.pl przezroczysty, bo związane były one ze zmianą infrastruktury i firmy obsługującej portal dotychczas.

To na portalu wss.pl stawiałem pierwsze kroki jako początkujący administrator. Spotkałem się wtedy z dużą otwartością i pomocą innych osób, mających bogatszy bagaż doświadczeń. Do niedawna pełniłem też tutaj funkcję moderatora forum. W chwili obecnej po kilku latach zdobywania doświadczenia zajmuję się projektowaniem i wdrażaniem usług opartych o środowisko Windows.

Co się z tym wiąże, z dużą radością przyjąłem informację o chęci przeniesienia obsługi portalu przez Microsoft do firmy Centuria Sp. z o.o. z którą jestem aktualnie związany. Ze względu na moje wcześniejsze powiązania z wss.pl byłem żywo zainteresowany tym, aby portal nie ucierpiał, ale przy okazji planowanych zmian zyskał jak najwięcej.

Portal wss.pl przeszedł ostatnio wiele zmian. Część z nich była łatwo zauważalna i polegała na dodaniu nowych funkcjonalności lub usunięciu niedociągnięć. Sporo prac odbyło się jednak w sposób zupełnie dla czytelników wss.pl przezroczysty, bo związane były one ze zmianą infrastruktury i firmy obsługującej portal dotychczas.

Jako że wss.pl skupia specjalistów IT myślę, że dobrym pomysłem jest podzielenie się z Wami informacją jak migracja wyglądała od strony technicznej. Oczywistym założeniem był fakt, że migracja powinna być jak najmniej zauważalna dla użytkowników i wiązać się z możliwie najkrótszą przerwą serwisową.

Portal przenoszony był do nowej serwerowni i na nowe serwery. Co się z tym wiązało, zmianie ulec musiały adresy IP pod którymi był on dostępny. Przeprowadzenie płynnej migracji stanowiło więc ciekawe wyzwanie.

Choć migracja składała się z kilku etapów, to kluczem do jej sukcesu było dobre zaplanowanie zmian w systemie DNS. Opis całej migracji chciałbym więc rozpocząć od skrótowego przypomnienia zasady działania usługi DNS.

Dygresja na temat DNS

Zanim zawartość strony internetowej będzie mogła być wyświetlona na ekranie komputera musi zostać zestawiony kanał transmisji TCP. Konieczne jest więc poznanie obu końców połączenia (adres IP i port źródłowy, adres IP i port docelowy).

Adres IP źródłowy jest znany - komputer podłączony do sieci ma go w konfiguracji swojej karty sieciowej. Numery portów po stronie klienta też są znane (wybierane losowo z określonej puli).

Po stronie serwera numer portu jest jednoznacznie identyfikowany przez aplikację z której chcemy korzystać (w naszym przypadku port 80). Jedyną niewiadomą pozostaje adres IP z jakim powinniśmy się połączyć, aby móc pobrać interesujące nas informacje. Znamy jednak nazwę strony, a to wystarczy. Tu z pomocą przychodzi nam bowiem system DNS, tłumaczący nazwy na adresy IP.

Ogólny schemat działania DNS przedstawiony został na rysunku 1.

Rysunek 1 - Ogólny schemat działania usługi DNS

Rysunek 1 - Ogólny schemat działania usługi DNS

Prześledźmy go na konkretnym przykładzie. W przypadku domeny wss.pl zapytanie DNS trafia w pierwszej kolejności do tzw. root-serverów (ich lista jest publicznie znana), które przekazują informacje o serwerach obsługujących domeny pierwszego poziomu (w naszym przypadku root-server podaje adres serwera właściwego dla domeny .pl).

Następnie serwery obsługujące domeny .pl  przekazują adres serwerów DNS właściwych dla domeny wss.pl. Dopiero serwery DNS domeny wss.pl mogą przekazać informację o adresie IP związanym z nazwą wss.pl.

W imieniu komputera użytkownika zapytania DNS wykonuje najczęściej serwer DNS sieci lokalnej. Dzięki temu możliwe jest czasowe zapamiętanie w pamięci podręcznej poprzednio zwróconych wyników i znaczne skrócenie czasu odpowiedzi na kolejne zapytania o ten sam adres.

Nietrudno zgadnąć, że mechanizm pamięci podręcznej choć znacznie przyspiesza rozwiązywanie nazw na adresy IP, będzie powodował znaczne utrudnienia w przypadku konieczności szybkiej aktualizacji wpisów stref. Zmiany są bowiem zapamiętywane w całej drzewiastej strukturze i odświeżenie wpisów na wszystkich serwerach może potrwać nawet kilka dni.

Migracja portalu wss.pl

Przygotowania do migracji

Każde wdrożenie czy projekt ma zawsze jakieś terminy, których nie można przekroczyć. W przypadku wss.pl główna wytyczna była jedna - zdążyć przed 31 stycznia 2009. Wszyscy wiemy, że projekty informatyczne zajmują zawsze tyle czasu ile się na nie przeznaczy. Dlatego też migracja została zaplanowana tak, jakby terminem ostatecznym była data 22 stycznia. Dawało to jeszcze około tygodnia dodatkowego czasu na wypadek gdyby cały plan wywrócił się do góry nogami.

Początkowo obsługa zarówno serwerów DNS jak i samego ruchu WWW leżała po stronie firmy Xenium. Adres IP portalu zawierał się w puli adresowej Xenium. Co się z tym wiązało, nie było możliwe przeprowadzenie migracji portalu z zachowaniem dotychczas używanego adresu IP.

Ogólny schemat komunikacji przed przystąpieniem do prac związanych z migracją wyglądał tak jak na rysunku 2.

Rysunek 2 - Stan przed migracją

Rysunek 2 - Stan przed migracją

Komunikacja odbywała się w całości w oparciu o zasoby firmy Xenium. Konieczne było więc wprowadzenie zmian w delegacji domeny, zmodyfikowanie wpisów w strefach DNS oraz przeniesienie danych portalu na nowe serwery.

W związku z tym, że infrastruktura portalu oparta była o pojedynczy serwer bazodanowy, wiadomo było, iż przeniesienie bazy trzeba będzie zsynchronizować i na pewien czas portal wyłączyć. Baza nie była duża, więc planowana przerwa nie powinna była trwać dłużej niż kilkadziesiąt minut.

Większym problemem była jednak konieczność zmiany adresu IP. Zmiany w systemie DNS propagują się często około 24 godzin, a czasami nawet dłużej. Oczywistym jest, że nie mogliśmy pozbawić Was na tak długo dostępu do wss.pl. Trzeba było wymyślić sposób na skrócenie czasu i rozpropagowanie zmian na serwerach DNS bez wpływu na działanie portalu. Zaczęliśmy od zmiany delegacji domeny.

Etap 1 - zmiana delegacji serwerów DNS

Pierwszym krokiem migracji była zmiana adresów serwerów DNS obsługujących domenę wss.pl z jednoczesnym przeniesieniem niezmienionej zawartości plików stref DNS.

Prace które miały miejsce w ramach tego etapu zobrazowane zostały na rysunku 3

Rysunek 3 - Etap pierwszy migracji

Rysunek 3 - Etap pierwszy migracji

Po zmianie delegacji serwerów DNS na serwery Centurii, wszystkie zwracane zapytania DNS były dokładnie takie same jak przed wprowadzeniem zmian.

Etap ten miał na celu wprowadzenie łatwej kontroli nad zawartością stref DNS i umożliwienie dokonywania dalszych zmian bez angażowania osób z zewnątrz. Wprowadzone zostały zmiany, które spowodowały, iż wszystkie zapytania DNS związane z domeną wss.pl był obsługiwane przez serwery Centurii.

Stare serwery DNS cały czas działały, dzięki czemu podczas propagacji zmian w Internecie, pytania DNS trafiające pod nieaktualne adresy także były prawidłowo obsługiwane. Z punktu widzenia użytkowników, portal działał cały czas bez przerwy. Wszystkie żądania HTTP obsługiwane były nadal przez te same serwery WWW po stronie Xenium.

W tym samym czasie trwały oczywiście intensywne prace i testy migracyjne, polegające na przeniesieniu kodu portalu i uruchomieniu go z testową wersją bazy danych na nowych serwerach. Ten etap był przygotowaniem do etapu drugiego - chyba najważniejszego w całej migracji. Etap pierwszy zakończył się 16 stycznia 2009.

Etap 2 - zmiana adresu IP

Był to najważniejszy i tak naprawdę kluczowy moment całej migracji. Nie wiem ilu z Was zauważyło, ale zmiana adresu IP pod jakim widoczny jest portal nie nastąpiła w dniu oficjalnie ogłoszonej migracji 22 stycznia, ale dużo wcześniej.

Pewnie część z Was zadaje sobie pytanie, dlaczego? Zastanówcie się, co by się stało, gdybyśmy zmianę taką wykonali dopiero w dniu migracji. Mając na uwadze opisane wcześniej fakty, większość z Was przez wiele godzin (jak nie dni)  korzystałoby ciągle z nieaktualnych już adresów IP. Dopiero po rozpropagowaniu się zmian w Internecie portal zacząłby być osiągalny.

Pomysł na rozwiązanie tego problemu był więc następujący. Na naszym serwerze skonfigurowany został adres IP pod którym docelowo widoczny miał być portal wss.pl. Wszystkie pakiety trafiające na ten adres IP były z kolei tłumaczone (NAT - Network Address Translation) na adres IP serwera Xenium.

Co więcej, żeby komunikacja w ramach TCP zadziałała poprawnie, w pakietach tych zmieniany był dodatkowo adres IP źródłowy na adres naszego serwera.

Było to konieczne, ponieważ bez zmiany adresu IP źródłowego serwery Xenium odpowiadałyby bezpośrednio do użytkowników, którzy się z kolei z tymi serwerami nie łączyli. Tym samym nie byłoby możliwe nawiązanie sesji TCP i komunikacja nie funkcjonowałaby poprawnie.

20 stycznia 2009 był bardzo ważnym dniem dla całego projektu. To właśnie wtedy zmieniony został adres IP strony portalu na nowy. Dla użytkowników nie był to żaden szczególny okres. Dla nas był to jednak czas dokładnego badania charakterystyki ruchu, przewidywanego obciążenia, sprawdzania czy wszystko działa jak powinno.

Ogólny schemat komunikacji po wprowadzeniu tych zmian przedstawiony został na rysunku 4.

Rysunek 4 - Etap drugi migracji

Rysunek 4 - Etap drugi migracji

Nie było tutaj żadnej przerwy w obsłudze ruchu portalu. Dla tych użytkowników, którzy korzystali z nowego adresu IP ruch na serwerach Centurii kierowany był przezroczyście na stare serwery.

Dla użytkowników, do których zmiany w DNS nie dotarły, komunikacja nadal działała po staremu. Portal cały czas funkcjonował bez jakichkolwiek zmian po stronie produkcyjnej infrastruktury.

Od dnia 20.01.2009 w Internecie propagowały się już zmiany w DNS. Pozwoliło to w ostatnim etapie migracji w ciągu kilkudziesięciu minut przełączyć ruch portalu na nowe serwery. Jak się pewnie już domyślacie, w kolejnym etapie był to czas potrzebny na skopiowanie aktualnej zawartości bazy danych.

Etap 3 - przeniesienie bazy danych

Etap trzeci był ostatecznym zamknięciem procesu migracji. Mając aktualne wpisy w DNS przełączenie ruchu IP na docelowe serwery mogliśmy zrobić w bardzo prosty sposób - wyłączyć ustawione wcześniej tłumaczenia adresów IP (NAT).

W tym momencie ruch przestawał być przekazywany dalej i trafiał już bezpośrednio na serwery Centurii. Zamknięcie migracji ustalone na dzień 22.01.2009 godz. 23:00 rozpoczęło się planowo.

Portal był niedostępny łącznie przez około 45 minut. Wyłączenie portalu było niezbędne aby móc wykonać kopię bazy i przenieść jej aktualną wersję na nową infrastrukturę. Operacja ta przebiegła bez zakłóceń.

Po upewnieniu się, że wszystko działa prawidłowo, wyłączone zostały ustawione kilka dni wcześniej przekierowania ruchu IP. Żadne zmiany w DNS nie były już potrzebne, ponieważ wszystkie modyfikacje zostały wykonane kilka dni wcześniej.

Pakiety IP praktycznie od razu zaczęły więc trafiać na serwery Centurii. Był to koniec migracji.

W związku z tym, że część użytkowników mogła mieć jeszcze z jakiegoś powodu nieodświeżone stare wpisy w DNS, ustawione zostały przekierowania w drugą stronę: wszystkie pakiety trafiające na stare adresy IP po stronie Xenium były przekierowywane na nowy adres portalu.

Dało to kolejnych kilka dni buforu czasowego na ostateczną propagację zmian w DNS do końca stycznia 2009, kiedy to stara infrastruktura została ostatecznie wyłączona. W efekcie końcowym ruch portalu obsługiwany był po zakończeniu etapu trzeciego tak jak na rysunku 5.

Rysunek 5 - Etap trzeci migracji

Rysunek 5 - Etap trzeci migracji

 

Obecna infrastruktura serwerowo - sieciowa portalu

 

Portal w trakcie migracji został przeniesiony na zupełnie nową infrastrukturę serwerowo-sieciową. Zakupione zostały całkiem nowe serwery i zainstalowane zostało najnowsze oprogramowanie.

Całość swoje miejsce znalazła w serwerowni Beyond.pl - to miejsce, gdzie znajdują się takie portale jak Allegro czy Nasza-Klasa. Dzięki temu mieliśmy pewność, że sama infrastruktura sprosta aktualnym i przyszłym potrzebom portalu.

Sprzęt

Infrastruktura serwerowo-sieciowa portalu wss.pl oparta została o trzy dedykowane serwery IBM HS21, każdy w następującej konfiguracji:

  • 2 procesory Intel Xeon Quad-Core 5405
  • 8GB RAM
  • 2 dyski SAS 146GB
  • 2 karty sieciowe 1Gbit

Do każdego z serwerów możliwy jest dostęp w trybie niezależnym od systemu operacyjnego. Pozwala to na zdalny dostęp do konsoli serwera nawet w sytuacji bardzo poważnej awarii systemu operacyjnego.

Serwery podłączone są do dwóch niezależnych torów zasilających, do dwóch przełączników sieciowych i korzystają z łączy dostępowych do Internetu w oparciu o protokół BGP, co pozwala dynamicznie kierować ruch najbardziej optymalnymi trasami i chroni przed awarią u pojedynczego dostawcy usług internetowych.

Całość infrastruktury objęta jest całodobowym aktywnym monitoringiem wielu parametrów pracy serwerów.

Oprogramowanie

Na wszystkich trzech serwerach zainstalowany został najnowszy na chwilę obecną serwerowy system operacyjny Microsoft Windows Server 2008 Standard. Infrastruktura zorganizowana została zgodnie z rysunkiem 6.

Rysunek 6 - Ogólny schemat komunikacji

Rysunek 6 - Ogólny schemat komunikacji

Dwa z serwerów pełnią rolę serwerów WWW i load-balancerów, a trzeci serwera bazodanowego.

Baza danych obsługiwana jest przez Microsoft SQL Server 2005 Standard. Sam portal działa w oparciu o serwer IIS 7 oraz ASP.NET 2.0.

Jako mechanizm równoważenia obciążenia wykorzystana została wbudowana usługa systemów Windows, pewnie większości z Was doskonale znana - Network Load Balancing. Konfiguracja NLB  została przygotowana tak, aby ruch z Internetu rozkładał się równomiernie na oba serwery WWW. Oznacza to, że oba serwery posiadają bardzo zbliżoną konfigurację i muszą korzystać z dokładnie tych samych wersji wszystkich plików związanych z portalem.

Serwery obsługujące ruch internetowy poza rolą IIS 7 posiadają zainstalowany dodatek Streaming Media Services. Usługa ta jest wykorzystywana na potrzeby udostępniania na portalu Webcastów i innych materiałów wideo.

Warto tutaj dodać, iż komponent ten w systemie Windows Server 2008 musi zostać doinstalowany z dodatkowej paczki, którą oczywiście można za darmo pobrać ze stron Microsoft.

Na potrzeby monitoringu doinstalowana została także usługa SNMP, dzięki której możliwe jest bieżące śledzenie stanu wielu parametrów pracy systemów operacyjnych.

Podsumowanie

Informacje o migracji celowo nie były zbyt powszechnie publikowane. Głównie dlatego, że utrudniłoby to odróżnienie prawdziwych problemów od informacji o błędach które już wcześniej występowały, ale których nikt usilnie nie szukał.

Myślę jednak, że warto było po fakcie napisać jak to wszystko wyglądało od kuchni, żebyście mieli świadomość zmian jakie zaszły. Mam nadzieję, że wss.pl będzie się dzięki temu jeszcze prężniej rozwijał, a zmiany będą miały wyłącznie pozytywny wydźwięk.

Kto za tym stał?

Praca administratora sprowadza się najczęściej do tego, że dobrze wykonywane obowiązki są niezauważalne dla użytkowników. Przeprowadzenie wszystkich prac możliwe było tylko dzięki współpracy wielu wspaniałych osób, z których każda wykonała niezawodnie swoją część prac.

To wszystko nie byłoby możliwe, gdyby nie współpraca Centurii, Microsoft i Xenium. W tym miejscu chciałbym zatem podziękować wszystkim tym, dzięki którym migracja odbyła się tak sprawnie.

W pierwszej kolejności chciałbym podziękować kolegom z pracy:

  • Piotrowi Michońskiemu, który razem ze mną zajmował się zmianami związanymi z ruchem sieciowym i z którym razem wymyśliliśmy cały przebieg projektu migracji. Gdyby nie dobry projekt, zmiany na pewno nie byłyby tak niezauważalne.
  • Mikołajowi Jaśkowskiemu, który był odpowiedzialny za analizę i migrację kodu wss.pl i który wykonał kawał dobrej roboty, nie opisanej tutaj ze względu na charakter portalu, ale który mógłby pewnie bardzo dużo ciekawego napisać programistom.
  • Wojtkowi Lesickiemu, który był przy serwerach od samego początku, instalował systemy i precyzyjnie określił reguły dostępu do usług z zewnątrz.
  • Pozostałym osobom z firmy zaangażowanym pośrednio w projekt, Pawłowi Długoszowi, Przemkowi Bromberowi, a także prezesowi Centurii Sp. z o.o. - Maciejowi Kalkowskiemu, który był dobrym duchem projektu i do końca służył nam pomocą.

Podziękowania należą się także Microsoft :

  • Mariuszowi Kędziorze, który od początku do końca dbał o każdy detal, odpowiadał na maile w środku nocy, służył nam pomocą, a jako doświadczony administrator pełnił jednocześnie rolę krytyka przedstawianych pomysłów związanych z migracją.
  • Kasi Pawlonce oraz Małgosi Nowak-Piszlewicz, które pomagały przezwyciężać trudności formalne, pilnowały odpowiedniego tempa prac i dbały o trójstronną komunikację.

Migracja nie byłaby możliwa, gdyby nie pomoc Xenium, ze strony którego zaangażowani byli:

  • Tomek Bryja i Wojtek Kowasz, którzy odpowiadali na bieżące pytania i pomogli sprawnie przenieść dane portalu do nowej lokalizacji.

I w końcu podziękowania należą się także przedstawicielom portalu wss.pl, czyli członkom redakcji portalu z redaktorem Robertem Stuczyńskim na czele. Dzięki dobrej, ścisłej współpracy z gronem redakcyjnym mogliśmy łatwo wyłapać wszelkie niedociągnięcia i błędy. To dzięki nim wiele usterek zostało usuniętych przed ostatecznym zmigrowaniem portalu.

Bardzo miło było współpracować z ludźmi, dla których wss.pl to nie tylko kod źródłowy, ale przede wszystkim koledzy i koleżanki skupieni wokół technologii Microsoft, gotowi do pomocy i chętni do dzielenia się wiedzą z innymi. Dziś chyba nikt nie ma wątpliwości, że wokół wss.pl skupione jest silne grono wybitnych specjalistów. Wierzę, że wprowadzone zmiany zachęcą Was do jeszcze większej aktywnej działalności na portalu i wspólnej wymiany doświadczeń. Do zobaczenia na wss.pl !

 

Photo

Autor: Paweł Damian (MCSE, MCT, CCNA, SEClub)

Paweł Damian pracuje jako inżynier systemowy i sieciowy w firmie Centuria sp. z o.o. Na co dzień projektuje i wdraża rozwiązania systemowe oparte o systemy Windows oraz wysokowydajne sieci komputerowe.

Komentarze 7 Masz uwagi do tej strony? Napisz

wysoki 2009.04.24 14:40
0 oceń pozytywnie   oceń negatywnie 0
avatar
 
Super art, bardzo przyjenie sie go czytało!

pozdrawiam i zycze dalszych sukcesów!

--
wysoki
CCNA

-- wysoki CCNA

splitmode 2009.04.24 15:04
0 oceń pozytywnie   oceń negatywnie 0
avatar
 
Dobra robota, ale mam dodatkowe pytanie:

...i muszą korzystać z dokładnie tych samych wersji wszystkich plików związanych z portalem.

W jaki sposób zrealizowany został dostęp do plików związanych z portalem, gdzie są przechowywane? Na schemacie nie ma zasobów po fc, sambie, etc. Jeżeli są lokalnie przechowywane na WH06, WH07 to jak są synchronizowane?

Pozdrawiam i jeszcze raz gratuluje wykonanej pracy.

--
/dev/drzewo

bachus 2009.04.24 18:07
0 oceń pozytywnie   oceń negatywnie 0
avatar Ekspert WSS
 
Ciekawie napisane, jednak mimo wszystko pisząc o świadomości czytelników (czyli w większości ludzie mający większe pojęcie o systemach, niż wsadzenie płytki instalacyjnej i wpięcie kabelka sieciowego), wypada kilka słów chociaż napisać o sieci, albo np. jak już ktoś napisał o uruchomieniu SNMP, jakie oprogramowanie zostało użyte do monitoringu (to tak, jakby napisać, że został uruchomiony POP3 i WWW).

Dominik Siedlak (bachus)
MS: MCP, MCTS, MCSA 2003

http://itblog.bachus.org - blog IT jaki jest, każdzy widzi ;-)
Dominik Siedlak (bachus) MS: MCP, MCTS, MCSA 2003

Luke999 2009.04.24 23:59
0 oceń pozytywnie   oceń negatywnie 0
avatar
 
Guys :) Z tym czasem propagacji to trochę zdemonizowaliście problem :) Wystarczyło ustawić sobie na czas przeniesienia TTL rekordu np. na 900 sekund :)

--
BR

Łukasz

BR

Łukasz

kams 2009.04.25 14:53
0 oceń pozytywnie   oceń negatywnie 0
avatar
 
Łukaszu,

Zauważ, że wtedy zwiększyłby się ruch sieciowy a co za tym idzie wykresy nie trzymałyby jakiegoś "baseline". Pozatym NAT który został zastosowany zapewnił 100% działanie cały czas a jednak przy małej TTLce masz tą chwilę kiedy nie działa.
-- Pozdrawiam MCSE, MCSA+M, RHCE, CCNA, 1/4CCNP
kams 2009.04.25 14:56
0 oceń pozytywnie   oceń negatywnie 0
avatar
 
Zgadzam się. Prosimy więcej pikantnych szczegółów:)-- Pozdrawiam MCSE, MCSA+M, RHCE, CCNA, 1/4CCNP
horhe358 2009.04.29 8:56
0 oceń pozytywnie   oceń negatywnie 0
avatar
 
Przyślijcie mi proszę na maila informacje o czym chcielibyście żebym napisał więcej. Temat sieci celowo został opisany szczątkowo, bo musiałem tutaj wyważyć między bezpieczeństwem całej infrastruktury a ujawnianiem szczegółów. Pamiętajcie, że im więcej szczegółów zostanie ujawnionych, tym większe ryzyko że ktoś wykorzysta lukę w jakimś wykorzystywanym przez nas systemie. Postaram się jednak w miarę możliwości uzupełnić opis o informacje Was interesujące - napiszcie mi tylko proszę czego Wam brakuje.

pozdr.,
Paweł

Dodaj komentarz

avatar

Zaloguj się lub Zarejestruj się aby wykonać tę czynność.

Autor Paweł Damian
avatar
 

Windows Systems Administrator MCP, MCSA+S, MCSE+S, MCT, SEClub, CCNA

Załóż konto
WSS to serwis, który łączy dziesiątki tysięcy specjalistów IT w Polsce, zajmujących się szeroko pojętymi technologiami Microsoft. Portal działa od 2003 roku, i oprócz setek publikacji technicznych, rozwijającego się forum - portal to ludzie, którzy go tworzą. To właśnie z myślą o nich warto codziennie nas odwiedzać.

Dowiedz się więcej o WSS