ITblog

Po pierwsze chciałbym podziękować Tomkowi za jego felieton zatytułowany “O drapaniu się w lewe ucho przez prawe ramię“. Byłem pod dość dużym wrażeniem lekkości języka i czasu reakcji na mój post. Jednak Tomek pozwolił sobie na dość dużo skrótów myślowych, które mylnie wywnioskował z mojego postu. Fakt, moja wina - jeśli coś opisuje, powinienem się przykładać i opisywać rzeczy dokładnie jak się mają. Mleko się więc rozlało i cokolwiek bym teraz nie napisał, to regułą jest, że negatywne komentarze będą przeważały pozytywne.

Pamiętam jednak, że pisząc w szkole podstawowej do gazetki szkolnej, moja pani od polskiego zawsze mi powtarzała, że jak pisać artykuły, to rzetelnie i popierając to argumentami. Od tamtych słów minął już szmat czasu, ale zasada pozostaje taka sama. I w myśl tego credo chciałem odpowiedzieć na ten felieton.

Tomek podsunął mi w artykule pomysł. Dlaczegóż nie miałbym zamiast przesiadać się na Windows Server 2008 ze związanym z tym ceremoniałem, po prostu wykorzystać FTP do przesyłania tego samego pliku? W końcu moja propozycja aktualizacji jest na etapie projektu do skonsultowania, a nie jest gotowym planem migracji (dla osób nie mających doświadczenia z zarządzaniem projektami - business case to pierwsza faza, pomysł na projekt - do wdrożenia jest jeszcze całkiem długa droga).

Czemuż nie znaleźć alernatywy?

Zrobiłem zatem test przesyłu tego samego pliku poprzez FTP. Różnica między tym testem, a testem wykonanym w czwartek jest jednak dość znaczna: niedziela to czas, kiedy łącza nie są zapchane, kiedy kilka tysięcy osób nie siedzi na każdym z końców kabla wysyłając emaile, przeglądając strony intranetowe czy podobnie jak ja - przesyłając pliki przez FTP. Dałem więc FTP nieco lepsze warunki do popisu, niż miał to w czwartek SMB 2.0.

Warunki wykonania testu: Windows Server 2003 z serwerem FTP z IIS w Stanach, Windows Server 2003 z klientem FTP w Dublinie. Plik - dokładnie ten sam, wielkość 461865366 bajtów. Mode: bin. Polecenie: put.

Wynik: 20:10.

Lepszy niż przesył z wykorzystaniem SMB z Server 2003 (24:30), ale nie aż tak dobry jak ten z Server 2008 (dla przypomnienia: 4:45).

Zysk 4 minuty i 20 sekund. Więc dlaczego nie FTP? Problemów jest kilka. Jednym z nich jest autoryzacja. Nie chciałbym zostawić serwera otwartego na połączenia anonimowe, a przesyłanie otwartym tekstem haseł zupełnie nie wchodzi w rachubę. Ktoś mi natychmiast odpowie, że przecież mógłbym wykorzystać FTPS (SFTP), FTP poprzez SSH albo autoryzację przez Kerberos. No fakt, mógłbym, tylko że wtedy cytowane przez Tomka 30 minut na skonfigurowanie FTP (btw, to nie 30 minut bo ledwie 10) wydłuży się o dodatkowy czas na konfigurację SSH czy ściąganie (a może i nawet zakup) i instalację serwera FTP, który wspiera FTPS (IIS nie ma takiej obsługi, podobnie z FTP i Kerberos). Ponadto, poprzez szyfrowanie i związany z nim overhead nasz czas transmisji się wydłuży i może osiągnąć wynik porównywalny z SMB. Więc po co ta zabawa?

Drugim problemem jest integralność danych. FTP pozbawione jest kontroli przesyłu danych. Nie żyjemy w idealnym świecie idealnych łączy, więc może się zdarzyć, że moje połączenie zostanie przerwane. Odbiorca nie będzie więc wiedział, czy plik został przesłany w całości. Rozwiązaniem tutaj byłoby zastosowanie serwerów FTP, które obsługują sprawdzanie CRC czy innych sum kontrolnych. To jednak powoduje, że musiałbym zdać się na rozwiązanie firmy 3-ciej z całym dorobkiem z tym związanym. Dla 4 minut i 20 sekund (różnica pomiędzy SMB a FTP), to nie jest zabawa warta świeczki.

Dla zachowania takich samych warunków testu, spróbuje jutro w okolicach wieczornych znów przesłać ten sam plik przez FTP. Dla ciekawości, dla udokumentowania alternatyw.

Alternatywa alternatywy

W komentarzach do cytowanego felietonu znalazłem jeszcze wzmiankę o DFSR. Ten temat był poruszany w naszym zespole i wciąż się mu przyglądamy, ale dla wykorzystania wszystkich możliwości tego systemu musimy przebudować znaczną część modelu naszych usług. To o wiele większe planowanie, czas, praca i budżet niż aktualizacja dwóch serwerów do Windows Server 2008.

Marketing? To nie tutaj

Tomek dokonał kilku założeń, z którymi się można bądź nie zgodzić: sprzęt trzeba będzie wymienić (choć w moim przypadku nie trzeba), wydać mnóstwo kasy na wersję Enterprise (a przecież jako serwer plików to nawet Standard wystarczy), “sporo planowania” (ok, kilka rzeczy zaplanować trzeba), “niemało pracy” włożyć (backup - 10 minut, instalacja - 30 minut, konfiguracja - kolejne 30 minut, restore - 10 minut, testy - 60 minut; dużo?). Ale z tego wszystkiego najbardziej zadziwiło mnie to dziwne przypuszczenie, że kiedy pisze o technologii Microsoftu, na swoim prywatnym blogu, gdzie zastrzegam, że nie ma on związku z MS, to próbuję na siłę te technologie sprzedać.

Nigdy nie byłem dobrym sprzedawcą i doskonale zdaję sobie sprawę, że nigdy nim nie będę. Nie staram się nic nikomu na siłę wciskać, bo to kłóci się to z moim podejściem do wyboru technologii, aktualizacji czy zarządzania projektami IT. Jako pracownik Microsoftu, co Tomek łaskawie przypomniał, mam także do czynienia z innymi technologiami niż MS. Jak choćby na uczelni - Dublin Institute of Technology, gdzie pracuję na unixach, biorę udział w projektach sponsorowanych przez IBM i Google i uczestniczę w konferencjach, gdzie na ostatniej Jeff Hammerbacher z Facebooka pokazywał nam metodę synchronizacji baz MySQL pomiędzy Kalifonią a Wirginią. I choć czasami dość agresywnie staję w obronie technologii MS (o czym dobrze wie ptashek), to przemawia do mnie dobra argumentacja.

To tyle, ale na koniec …

Pomysł

W innym artykule Tomka o tytule “Windows Server - cud, czy bubel?” autor stwierdził, że SMB 2.0 powinno było dawno temu wyjść na rynek, a nie być sprzedawane jako nowy feature w Windows Server 2008. Poprzednia wersja SMB powinna była być potraktowana jako niedoróbka i jako taka naprawiona gratis w Windows Server 2003.

Mój pomysł jest taki. Tomku, postaram znaleźć w MS osobę, która była project managerem dla tego komponentu nowej wersji serwera i zapytam się go bądź jej, jak to dokładniej wyglądało i czy było możliwe dodanie SMB 2.0 do Windows Server 2003. Jeśli Cię to zainteresuje może być to nawet forma wywiadu, który będziesz mógł opublikować na swoim portalu TechIT.pl. Sam jestem ciekawy jak to dokładnie było.