Coś z firmowego podwórka, z placu boju chciałoby się napisać.
Mój zespół ma pod opieką dwie serwerownie, na dwóch kontynentach, które działają jako jeden organizm dostarczając pewnej usługi naszym klientom (wew. grupy produktowe, programiści, etc). Jednym z kroków w procesie utrzymania takich samych warunków pracy obu serwerowni (a tym samym w zachowaniu jednolitości usługi) wymieniamy trzy razy dziennie między Redmond a Dublinem paczkę ZIP z plikami dla naszych serwerów. Oczędzamy w ten sposób czas i łącze, bo nie ślemy setek tysięcy plików poprzez WAN, a jedynie jeden duży - około 450, 500MB.
Nasze “brzegowe” serwery działają na Windows Server 2003 Enterprise już od kilku dobrych lat. Jakiś czas temu zaczęliśmy się przyglądać w jaki sposób zoptymalizować nasze usługi, skrócić czas potrzebny na wykonanie usługi dla klientów, etc. Efektem optymalizacji było między innymi stworzenie wspomnianej przeze mnie “paczki” zamiast tysięcy plików.
Kilka dni temu zaczęliśmy się przyglądać benefitom z prowadzenia Windows Server 2008 zamiast 2003. Pytanie zasadnicze: jak długo trwałoby skopiowanie poprzez WAN pliku 450MB z jednego końca na drugi? Wczoraj wykonałem zatem ten test.
Nie interesowała mnie przepustowość łącza, bo ta jest dla nas niezmienna i byłoby dla nas dość kosztowne by tą przepustowość zwiększyć. Interesował mnie jedynie czas jaki można uzyskać w tych samych warunkach, ale na różnych platformach. Narzędzie jakie wykorzystałem to zwykłe robocopy z Resource Kit 2000, standardowo dostarczane z Windows Server 2008.
- Test pomiędzy Dublin a Redmond, 450MB, Windows Server 2003 x2. Czas: 24:30
- Test pomiędzy Dublin a Redmond, 450MB, Windows Server 2008 x2. Czas: 4:45
Powtórzyłem oba testy jeszcze dwukrotnie. Różnice nie sięgnęły 10% w obu przypadkach. Efektem tego testu był business case dla nowego projektu aktualizacji naszych systemów brzegowych na platformę Windows Server 2008. Dlaczego projekt? Bo to jednak dość skomplikowane przeszczepiać aortę na otwartym organizmie i wymaga nieco organizacji i staranności w wykonaniu.
O wiele lepsze rezultaty od moich są opisane na blogu Windows Server Division WebLog: Some Cool Networking Numbers with Windows Server 2008 File Transfers.
Technologie sieciowe z Windows Server 2008 opisane są na Technet.
A jakiego protokołu używacie do transportu plików i samego strumienia (VPN)?
@Jakub: nie wiem. Zapytam sie sieciowcow
sieciowców? co wy tam macie od wszystkiego oddzielny dział? a macie dział od “sapera” albo od “pasjansa” ? ;D
Juz sie z Ciebie Michale smiejemy w kraju.
Mam nadzieje, ze Ci tam na Zielonej Wyspie dobrze i do kraju najwczesniej na emeryture wrocisz.
http://www.techit.pl/MoimZdaniem/View.aspx?1929.o drapaniu sie w lewe ucho przez prawe ramie
Podobne jest ograniczenie transferu w LAN do 20MB/s tylko że to da się wyłączyć http://google.com/search?q=cache:www.evga.com/forums/tm.asp?m=264268 sam to sprawdziłem, ciekawe czy w tym przypadku nie jest tak samo.
http://technet2.microsoft.com/windowsserver/en/library/EFA621BD-A031-4461-9E72-59197A7507B61033.mspx
a nie lepiej ftp ? tak samo szybko (jak ws2k8) a duzo taniej ? (no i czas wdrożenia nieporównywalny)
Mam nadzieje, ze twoj wordpressowy antyspam tego nie zje
http://dobreprogramy.pl/index.php?dz=15&n=9135&Felieton o drapaniu sie w lewe ucho przez prawe ramie
Michał: Jeśli naprawdę używacie SMB, to czy robiliście też “business case” porównania FTP, SCP, connect:direct, SMB i innych protokołów? Bo faktycznie wygląda jakbyćie się cieszyli z zysku, a naprawdę tylko częściowo odrabiacie stratę z powodu złego narzędzia…
noclegi: tak bywa w większych firmach, że się zatrudnia ludzi znających się na sieci jako sieciowców, programistów Javy w dziale programistów, a nie każe się gościowi który umie pisać zapytania w mySQL administrować klastrami Orakli “bo mówił, że się zna na bazach”.
@Jakub: zobacz moj ostatni post pt. Na skroty, ale przez las
@noclegi: u mnie jest tak ze zajmuje sie Lotusem i kompletnie nie interesuje mnie system operacyjny i jego konfiguracja - to nie moja dzialka - dostaja wytyczne konfiguracji systemu operacyjnego i tego sie maja trzymac; osobna grupa zajmuje sie tez hardwarem, osobna siecia i jeszcze pare innych ktorych nazw nie jestem w stanie wymienic