Windows Server | cancer's blog

Dzięki za regularne odwiedziny na moim blogu! Jeśli uważasz, że jest on godny polecenia to śmiało wyślij link do niego lub link do kanału RSS albo subskrypcje przez e-mail znajomym. Dzięki !

Wreszcie mogę napisać jakąś techniczną notkę, bo ostatnio coś nie mogłem się zebrać. Zrzucę to na wiosenne przesilenie ;) Dzisiaj będzie nietypowo ponieważ pochwalę Windowsa, a dokładnie rzecz ujmując Windows Server 2003 R2. Prawdę mówiąc nie jestem laikiem jeśli chodzi o Windows, ale dotychczas moje doświadczenie zawodowe było mało związane z Windowsami serwerowymi. Jednak przez całą moją dotychczasową działalność jako admina we wszystkich dżobach gdzieś się tam maszyny z serwerami Windows przewijały. Głównie SBS jako kontroler domeny, albo zwykły do obsługi MSSQL. Obecnie mam pod opieką wspomniany juz w2k3 server na DELL POWEREDGE 1800. Działa na nim Active Directory i wszyscy userzy są do niej podpięci. Zatem pełna kontrola z biurka w rozproszonej lokalizacji. Całkiem przyjemnie się tym zarządza. Ale to jakby tylko narzędzie dzięki któremu można znacznie ułatwić sobie pracę. Prawdziwym powodem dla którego podoba mi się Windows jest WSUS czyli Windows Server Update Service.. W skrócie chodzi o to, że nasz serwer Windowsowy przejmuje rolę witryny Windows Update.

Ustalamy jakie aktualizacje nas interesują (są nawet aktualizacje do odtwrzacza Zune jak i wszystkich innych programów MS o których istnieniu nawet nie wiedziałem), języki w których te aktualizacje będą dostępne oraz tworzymy grupy komputerów. Możemy oczywiście wrzucić wszystkie komputery z AD do jednej grupy, ale nasze polityki zakazują takich działań i najpierw poprawki muszą być testowane na maszynach do tego przeznaczonych.

Kiedy już nasz WSUS zsynchronizuje się z serwerami MS, a trochę to zajmuje czasu (dla poprawek dla Windows XP, 2000, Windows Server, oraz MS SQL i Office’a od 2003 do 2007 w 3 językach WSUS pociągnął 7,2 GB), trzeba tylko zadbać o dystrybucję poprawek. Załatwiamy to jedną polityką w głównym drzewie naszej domeny. Dobrą opcja jest wyłączenie automatycznego restartu komputera, co jest bardzo denerwujące kiedy się akurat nad czymś pracuje. Od tego momentu opcje w klientach dotyczących aktualizacji są wyszarzone co oznacza, że steruje nimi server. Admin ustala tylko które poprawki mają pójść gdzie, które odrzucić itp. i pod koniec dnia wysyła do klientów. Sprawnie, bez ingerencji u pracowników, z raportami co się powiodło a co nie.

Oczywiście można się spytać, po co to komu? Widzieliście duże biuro z zaktualizowanymi wszystkimi komputerami zostawionymi do dyspozycji użytkowników? Nie ma takich biur. Oprócz tego niedługo zostanie wydany SP3 dla XP (SP1 dla Visty szczęśliwie nas nie dotyczy :), można sobie tylko wyobrazić co się stanie jak kilkaset komputerów zacznie pobierać 200MB w jednym czasie.

Ok, wystarczy już może o samym Windowsie bo patrząc na tytuł i czytając do tego miejsca pewnie zastanawiacie się gdzie w końcu jest o NetBSD? :) Spokojnie właśnie nadchodzi ten moment. NetBSD również w mojej firmie odgrywa znaczącą rolę, a ilościowo przewyższa nawet maszyny z Windows Serwerem :) Oprócz całej gamy usług, typu groupware, obsługa eventów z Windows czy AS400, IDSa, statystyk, czy inwentaryzacji sprzętu (swoją drogą dzięki Group Policy Object czyli polityk Windowsowych zinwentaryzowanie i to bardzo dogłębne sprzętu i oprogramowania wraz z licencjami można wykonać nie ruszając się z biurka, a dostęp do wyników przez www z bazy mysql w NetBSD ;) NetBSD równierz udostępnia zasoby via Samba. Niestety miejsce na dyskach Windows Servera zaczyna się kończyć dlatego postanowiłem przenieść zawartość WSUS’a na udział Samby. Niestety WSUS nie przewiduje możliwości trzymania swojego content’u na czymś innym niż lokalny dysk z NTFS. Klapa? Nie zupełnie. Tutaj z pomocą również przychodzi NetBSD i obsługa iSCSI. Internet SCSI bo tak brzmi pełna nazwa tej technologii, to obsługa sieciowa dysków ale nie jako udostępnienie udziałów, tylko operacje na urządzeniu blokowym. Dodatkowo dyski można łączyć w jeden wielki wolumen albo stworzyć z kilku RAID. Skoro jest to urządzenie blokowe, klient (a właściwie initiator), może korzystać z serwera (a właściwie target’a) tak jakby korzystał z lokalnego dysku, może go sobie popartycjonować, sformatować itp. Jak więc sprawuje się target NetBSD i initiator Windows? Wyśmienicie się sprawuje! A co najważniejsze konfiguracja całości jest bardzo prosta.

Ze strony NetBSD nie musimy nic instalować, ponieważ target mamy w base systemie (mowa o 4.0).

Edytujemy tylko plik /etc/iscsi/target. Mój wygląda tak:

# extent file or device start length extent0 /usr/home/storage/iscsi-wsus 0 100000MB # target flags storage netmask target0 rw extent0 0.0.0.0/0

używam pliku o rozmiarze 100GB (rozmiar dynamiczny), initiator ma pełne prawa do tego dysku. Zamiast ścieżki do pliku możemy podać oczywiście całeurządzenia z /dev.

Ze strony MS, instalujemy oprogramowanie initiatora, wyszukujemy i podłączamy dysk.

Uaktywanimy go i formatujemy, nadajemy literę dysku.

W ostatniej zakładce, klikamy BIND ALL aby dysk iSCSI montował się przy starcie systemu.

Na sam koniec przenosimy zawartość WSUS’a, który już nie protestuje, że nie ma dysku lokalnego z NTFSem ;)

W logu widać czas, 9 minut dla 7GB danych w dość rozproszonej formie, jeśli dyskiem byłby faktycznie dysk a nie plik czas ten zapewne by się jeszcze skrócił.