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.
Skoro miałeś na początku taki rozrzut (20 min i 4) to nie lepiej na początku zastanowić się gdzie leży problem i wykonać testy sieci zamiast instalować nowy system ??
Jeśli smb w w2k3 nie jest zbyt dobre to może po prostu wystarczy http wget z drugiej strony - dobry pomysł na nowe business case z niewielkim nakładem pracy i kosztem licencji $0
Szanowny Michale!
Produkcyjny, i jak mniemam (skoro tak ważne jest by przyspieszyć kopiowanie o 20 minut) dość krytyczny , serwer wdrożony (i wytestowany) do produkcji w ciągu 60 minut? Ty sobie kpisz czy ironizujesz bo nie łapie? Bo jeśli serio to dziwne podejście jak na odpowiedzialnego sys-admina, bym powiedział - chałupnicze!
U nas w Polsce w całkiem poważnej firmie proces ten zajmuje min. miesiąc, a w przypadku krytycznych maszyn (głównie Unix i bazy Oracle) właściwie do skutku… Prędzej czy później wychodzą problemy czego oczywiście nikomu nie życzę.
Przeczytałem też post Tomka, i Twój poprzedni. I powiem tyle sam możesz mieć do siebie pretensje, trzeba było dołożyć informacje o testach z wykorzystaniem FTP lub wytłumaczyć czemu nie ma sensu pakować się w inne protokoły. I Twój post obronił by się sam. Ale z drugiej strony nie ma to jak rozgłos, co nie?
To nawet lepsze niż Windows Server 2020 i SMB 7.0 kopiująca pliki 100GB łączem 1Mb w 3,7 ms… 
Aha, jeszcze ostatni akapit, zapytasz Project MANAGERA? I myślisz, że powie Ci prawdę? O ile będzie chciał z Tobą rozmawiać sprzeda Ci bajkę, która być może (i tylko być może) okaże się prawdą… Pracowałem dobre dwa lata w firmie zajmującej się pisaniem oprogramowania dla klientów zewnętrznych i wiem jak to wygląda - INTERNAL BUG - do wiadomości wewnątrz firmy (oj było sporo takich niedoróbek, w sensie ze coś działało poprawnie, ale nie do końca - nie mylić z błędami.) Jeśli założymy, że Tomek ma rację - była jakaś niedoróbka w obsłudze protokołu SMB - to NIGDY się o tym nie dowiemy. Po prostu niedoróbka (bug) jest naprawiana w kolejnej wersji i dość często powoduje pojawienie się nowej funkcji w programie lub zwiększenia funkcjonalności istniejących. Dobrym przykładem było przepisanie w tymże programie modułu drukowania dokumentów seryjnych skutkujący zwiększeniem prędkości przekazywania zadań do drukarki (o jakieś 15% pozbyliśmy się efektu “zamulania” przy większych ilościach danych (a tak naprawę przesunęliśmy limit od którego sie “zamulanie” zaczyna znacząco do góry)).
I tak - Ty będziesz przekonany, że MS dokonało cudu, a Tomek będzie płakał, że poprzednia wersja to był bubel. I nikt z Was racji nie będzie miał albo rację będzie miał każdy (zależy kto i jak popatrzy).
Ave.
@Bart
(…) eśli założymy, że Tomek ma rację - była jakaś niedoróbka w obsłudze protokołu SMB - to NIGDY się o tym nie dowiemy. Po prostu niedoróbka (bug) jest naprawiana w kolejnej wersji i dość często powoduje pojawienie się nowej funkcji w programie lub zwiększenia funkcjonalności istniejących. (…)
Z całym szacunkiem - przeczytaj specyfikacje SMB, poczytaj troche na sieci i szybko sie dowiesz ze nie bylo bug’u czy czegos innego tylko SMB 1.0 byl tak a nie inaczej zaprojektowany i po prostu gadal po sieci za duzo. Stad sie braly takie a nie inne problemy z tym protokolem. Optymalizacja tego w v2.0 po prostu poprawila wydajnosc. Sorki … ale nie wszedzie u podstaw lezy tajmenica i teoria spiskowa. Problemy z SMB sa dobrze znane i opisane od X lat … przynajmniej dla tych, ktorym sie chce nimi zainteresowac.
powyższych komentarzy ie czytalem wiec moglo sie powtorzyc, ael od siebie dodam. Oficjalnie było mowione (a w technet nie za czesto wnika wiec mam informacje pobieżne), że przyspieszenie pracy w sieci Windowsa Vista / Server 2008 wynika z przepisanego stosu tcp/ip. Wątpię by dało się to zrobić jako poprawkę do Win2003 a jeśli się dało to na pewno nie opłacało.
@Tomek : a czy ja twierdzę, że jest inaczej??? W KTÓRYM MIEJSCU???
Przeczytaj jeszcze raz to co napisałem o INTERNAL BUG (oraz autentyczny przykład) bo chyba oderwałeś oczy i popatrzyłeś gdzieś poza monitor. Jest tak i w poważnej małej firmie jak i olbrzymich molochach w stylu Microsoft, Apple czy Sun.
I to nie są teorie spiskowe tylko procedury wewnętrzne. Myślisz, że w MS pracują debile? Przecież oni byli świadomi niskiej wydajności protokołu SMB 1.0 (to oczywiście domysł, ale wierzę że tak było, w końcu mamy SMB 2.0), ale kto o zdrowych zmysłach (kwestia dyskusyjna jeśli chodzi o menedżerów MS) strzela sobie samobója i przyznaje się, że wypościło niedopracowany produkt? Nikt. Vista też jest przecież świetna. Swoją drogą każdy kawałek softu z czasem i z pojawieniem się nowych wersji i alternatyw staje się “niedopracowany”.
Naprawdę fajnie jakbyśmy mieli WinNT Server 4.0 SP 17 (za darmo, oczywiście, ze wszystkimi funkcjami Win2k8) ale ten biznes tak nie działa. Po prostu.
Możesz sobie myśleć co chcesz, ba możesz wytoczyć proces MS-owi. Pisanie i wydawanie programów to coś więcej niż li tylko pisanie kodu, ba powiem więcej, pisanie kodu to jakieś 20% całej pracy. Reszta 80% to marketing (w szerokim ujęciu, nie tylko reklama) - kontrakty, terminy, za niedotrzymanie których nawet MS płaci. I tak oto mamy SMB 1.0. Może brakło czasu, może chęci i umiejętności. Nie po raz pierwszy z resztą.
I oczywiście, że nie było oficjalnych bugów ogłaszanych przez MS, bo po co, skoro SMB 1.0 spełniał podaną specyfikację. Równie dobrze można by powiedzieć że WinRAR 1.0 był bublem jakich mało… Bo z punktu widzenia wersji 3.7 tak właśnie jest. Na szczęście za WinRARa płaci się raz, ufff.
Zatem, co innego jakbyś miał gdzieś napisane że SMB 1.0 prześle pliki j/w w 4 minuty ale by tego nie robił (chociażby w pewnych okolicznościach), wówczas żale i pretensje o bugfixa są uzasadnione… zgoda też, że SMB 1.0 śmieci gadając do sieci, tylko co z tego, skoro w specyfikacji technicznej (nie mylić z materiałami marketingowymi) jest to na pewno napisane i stąd brak Public MS BugID. Powtórzę jeszcze raz: Naprawdę fajnie jakbyśmy mieli WinNT Server 4.0 SP 17 ale ten biznes tak nie działa. Po prostu… I za to nie lubię m.in. MS.
Na koniec tej miałkiej dyskusji (wybacz Tomku, uszanowanie, ale nie masz bladego pojęcia jak to wygląda “od kuchni”) skończę podsumowaniem które właśnie często słyszy się “od kuchni” i w kręgach w których się obracam:
It’s not a bug, it’s WOW (Way Oracle Works).
(…) Myślisz, że w MS pracują debile? Przecież oni byli świadomi niskiej wydajności protokołu SMB 1.0 (to oczywiście domysł, ale wierzę że tak było, w końcu mamy SMB 2.0), (…)
Hmmm … a myslisz ze w 91-92 roku kiedy SMB bylo implementowane to komus przeszkadzalo tak bardzo? Wtedy sieci wygladaly tak a nie inaczej i nawet jak SMB pracowal malo wydajnie to pewnie siec i tak byla wolniejsza od tego co mogl on wyprodukowac. Potem sieci sie troche rozwinely … i wtedy to zaczelo bardziej przeszkadzac.
I tak, wynikiem tego wszystkiego jest SMB 2.0.
(…) wybacz Tomku, uszanowanie, ale nie masz bladego pojęcia jak to wygląda “od kuchni” (…)
Widze ze dobrze znasz MS od srodka i orientujesz sie co moge wiedziec a czego nie, ale naprawde uwazasz mnie za takiego idiote i nawinwego zeby stwierdzi ze nie mam bladego pojecia jak to wyglada “od kuchni”? Moze i jestem tylko konsultantem w MCS ale nie jestem naiwny … i czasami nawet do nas dociera to i owo, i moze nie moge zajrzec do kodu ale do roznych miejsc w sieci tak … coz, ale nie zmienie Twojego przekonania o tym :).
Zreszta akurat zeby sie przeknac dlaczego SMB jest wolne nie trzeba wiedzy wewnetrznej … wystarczy network sniffer. Moze o tym tez nie mam bladego pojacie ale czasami uzywam … tak bezmyslnie.
@Bart: PMi z reguły nie kłamią, czasem jedynie (bardzo rzadko) nie są wystarczająco kompetentni by udzielić rzeczowej odpowiedzi. Trzeba także sporo samozaparcia (lub paskudnych doświadczeń) by wierzyć, że dwóch pracowników tej samej firmy będzie siebie nawzajem okłamywało. :-]
Jest jeszcze kwestia “niedopracowanego produktu”. Była kiedyś taka firma, co chciała wydać SQL Server bez błędów. Do czasu gdy usunęli wszystkie błędy ich technologia była już przestarzała. Mówimy o komputerach i oprogramowaniu: zawsze może być lepiej!
Zawsze też ludzie starają się, by kolejna wersja produktu była rzeczywiście lepsza. To dlatego programiści nie zdychają z głodu po wydaniu V1. A to, że coś nie działa tak dobrze jak mogłoby nie jest wynikiem złych intencji tylko realiów rynku i technologii. Realiów, z którymi boryka się każdy od MS czy Oracle przez Adobe, IBMa, po małą firmę z Koziej Wólki.
A SP17 jest nie jest ani dobre z punktu widzenia biznesu, ani z punktu widzenia klienta (choć, jak widać, nie każdy klient to rozumie). Zanim dostaniesz SP4 należy przetestować jak współdziała z SP0, 1, 2 i 3. Do czasu wydania SP17 macierz testowa jest tak gigantyczna, że szansa wydania SP17, które zadziała u większości klientów jest prawie zerowa. Ponownie: soft tak nie działa i wie o tym każdy, kto wydał 2-3 wersje jakiegoś produktu.
@Ryan: Nie do końca zrozumiałeś albo ja się niezbyt jasno wyraziłem. Oczywiście, że pracownicy nie będą siebie okłamywać, pod warunkiem, że są na odpowiednim poziomie w hierarchii firmy względem siebie
Zupełnie inna komunikacja przebiega między firmą a klientem…
@Tomek: Jeszcze wyjaśniając, nie chodzi Tobie przecież o samą implementacje SMB w 91 roku. Tylko o implementacje tegoż protokołu w WS2003, czy tak, bo się już gubię…
Mój post był poświęcony właśnie temu, i ani na chwilkę nie wrócił do prehistorii. Nie chce mi się dywagować na temat czemu MS zdecydował włożyć to do produktu z 2002, może goniły ich terminy, brakowało wiedzy i umiejętności, może jakiś pożal się Boże menedżer uznał ze to mało istotne, może wszystko naraz.
Jak pisze Ryan i co napisałem ja, jeszcze raz i po ludzku: MS by zdechł z głodu gdyby każdą swoją niedoróbkę naprawiał patchem czy SP. I przecież nie tylko MS.
Przyznaję jest ból ale tak naprawdę my biedni klienci NIC nie możemy zrobić, ew nie kupować, poszukać alternatyw. Więc jeśli Pan Michał nie ma alternatywy i musi użyć SMB do przesyłania plików j/w…
PS: Bardzo bym prosił o rzeczową dyskusję a nie wyrywie dwóch zdań z kontekstu.
@Bart: wierz lub nie, ale poziom w hierarchii nie ma znaczenia. Jeśli informacja jest z jakiegoś powodu utajniona, w najgorszym wypadku pojawi się “nie mogę tego ujawnić”, ale o okłamywaniu mowy być nie może.
Hm, powiedziałbym, że może, ale nie powinno być
@Ryan: nie sposób się z Tobą nie zgodzić. Dzięki za doprecyzowanie moich wypowiedzi, bo faktycznie tak jest. W nic nie muszę wierzyć.
Nie zmienia to faktu, że często prawdy się nie dojdzie.