Hyper-V z CSV cd…

w końcu wszystko zahulało i od dwóch dni mam świetną zabawę testując czasy przenoszenia maszyn. nie tracą nawet pojedynczego pinga (: średnia prędkość kopiowania przy LM: 3ooMbps. teraz tydzień-dwa testów – ale wygląda na to, że osiągnąłem stabilizację środowiska.

co było nie tak, że CSV się wieszał? nie znalazłem finalnej odpowiedzi ale kilka wskazówek:

  • znalazłem ciekawy art, w którym jest opisane podobne zachowanie – nie mój scenariusz ale warto się zapoznać
  • zrobiłem kilka zmian, po których zaczęło wszystko działać ‘ez expekted’ – podstawową było wyeliminowanie jednego ze switchy. czy była to kwestia jakiś problemów na styku HP/Cisco , czy problem MPIO – tego nie wiem, a testować już nie będę. tak jest docelowo i nie ma co komplikować.
  • drugą zmianą która mogła [choć nie powinna] mieć wpływ to włączenie obsługi jumboframes na obu węzłach

wygląda na to, że fundamenty stoją. kilka nuketestów i redukujemy fizyczne klocki (:

eN.

Hyper-V cluster i Cluster Shared Volumes

 

na ten temat znaleźć można wiele artykułów od stron technet po wpisy na blogu:

to tylko kilka przykładów [polecam zwłaszcza ten ostatni]. niemniej jest kilka pytań, na które nie umiałem znaleźć odpowiedzi. a więc podsumowując oraz co nieco dodając…

konfiguracja interfejsów sieciowych na Hyper-V Cluster

to największy problem i najbardziej zagmatwany. wykorzystanie interfejsów sieciowych jest co najmniej nieintuicyjne – zarówno dla klastra jak i samego Hyper-v. po pierwsze ile ich jest potrzebne:

  • potrzebne są oddzielne interfejsy dla:
    • iSCSI [jeśli używane do dostępu do macierzy]. oczywiście sugerowana redundancja.
    • heartbit + LiveMigration
    • Host Network – komunikacja z węzłem, HV, i inne takie
    • Virtual Switch – min. jedna ale oczywiście zależne od ilości maszyn

w niektórych artykułach jest wręcz przykazane, aby było jeszcze jedno połączenie – dedykowane dla Clustered Shared Volumes. jako niebezpieczeństwo łączenia funkcji heartbeat i LM jest możliwośc pełnego wysycenia podczas migracji i utraty heartbeatu – a co za tym idzie zfailowania całego klastra. nie wiem na czym dokładnie polega komunikacja CSV i jakie są jej wymagania – nie udało mi się tego odnaleźć w żadnym z artów.

jak widać, zakładając wykorzystanie iSCSI, minimalna sugerowana ilość to 4 interfejsy. 3 wykorzystane na samą infrastrukturę. teraz druga kwestia – jak toto skonfigurować?

  • iSCSI – interfejs powinien mieć wyłączone wszystkie dowiązania protokołów (bindings) poza niezbędnym, czyli TCP/IP – v4 lub v6 zależnie z której korzystamy. obecnie można przyjąć, że v4 – tak zapewne ma 99,9% środowisk.
    • numeracja sieci: prywatna, bez zdefiniowanego GW
    • w konfiguracja klastra ta sieć powinna być oznaczona jako ‘do not allow cluster network communication on this network’. nie chcemy przecież zaśmiecać iSCSI…
    • konfiguracja zazwyczaj oparta na VLANach – należy pamiętać o zapewnieniu maksymalnej redundancji
  • heartbeat + LiveMigration + CSV – do wymiany danych przy LM powinien być dedykowany interfejs. imho można zaryzykować i połączyć te role. UWAGA! sugerowane są dwa oddzielne interfejsy – jeden na CSV+HB drugi na LM. tylko zaczyna się ich robić strasznie mało dla maszyn…
    • numeracja sieci – prywatna [inna niż dla iSCSI], bez zdefiniowanego GW. połączenie najlepiej fizyczne – bezpośrednie. ew. może być VLAN [ale po co sobie utrudniać życie?]
    • ze względu na Cluster Shared Volumes muszą być włączone protokoły ‘Client for Microsoft Network’ oraz ‘File and Printer Sharing for Microsoft Networks’
    • no i oczywiście TCP/IP w odpowiedniej wersji
  • Host Network – czyli zwykły dostęp do serwera.
    • numeracja sieci: sieć lokalna, powinien być oczywiście GW i DNS. na podstawie tego czy GW jest zdefiniowany czy nie, algorytm LM dobiera sieć, którą będzie pchał dane. można to wymusić ręcznie, ale standard jest właśnie taki: na normalnym interfejsie jest GW, a na specjalnych go nie powinno być [ w większości to i tak połączenia punkt-punkt]. z tego też korzystają mechanizmy samej usługi clustra – w LABie trzeba było na siłę wpisywać GW bo głupek nie przyjmował takiego interfejsu q:
    • tu oczywiście można zostawić wszystkie wymagane protokoły wraz z QoS i LLT
  • Virtual Switch – czyli co najmniej jeden interfejs dla maszyn wirtualnych. raczej będzie ich sporo więcej. dla każdego takiego interfejsu zostanie utworzona karta wirtualna. przeważnie podczas konfiguracji VirtualSwitcha [czyli po prostu sieci] w Hyper-V, interfejs jest konfigurowany automatycznie.. ale nie zawsze. wynikowo jest tak: 
    • konfiguracja wymaga opisania obu interfejsów – fizycznego i wirtualnego:
      • fizyczny: można odbindować wszystkie protokoły. samego interfejsu nie można wyłączyć, bo wirtualny również przestanie działać. oczywiście trzeba zostawić ‘Microsoft Virtual Switch Protocol’.
      • wirtualny z HV: ponieważ fizyczny jest ‘przechwytywany’ i staje się switchem, wirtualny staje się jego odpowiednikiem – jest jako zwykła sieciówka, która może być wykorzystana do komunikacji. co z nią zrobić? można choćby wyłączyć – nie do końca znalazłem odpowiedź czy to czymś grozi ale na logikę.. nie powinno.

Cluster Shared Volume

czytając arty odnosi się wrażenie, że konfiguracja to kilka kliknięć. być może w labie – ale ja mam na drugie Murphy. owszem – wystarczy trochę poklikać i jest. jednak kilka ważnych informacji:

  • nie zapomnieć wywalić dedykowanych sieci – oznaczyć jako ‘do not allow cluster network communication on this network’  – np. iSCSI
  • trzeba sprawdzić której sieci używa cluster do komunikacji LiveMigration – jest to znów nieintuicyjne ponieważ sprawdza się we właściwościach zasobu a nie na poziomie samego clustra. dodatkowo jest dziwne – ponieważ zmiana tego ustawienia na pojedynczym zasobie jest globalna…
  • trzeba sprawdzić której siei używa cluster do komunikacji CSV – i tego już z GUI się nie zrobi.

inne takie…

  • bardzo nie chciałem serwerów HP – wsparcie tej firmy jest fatalne. i serwery są droższe. niestety zostałem pozbawiony wyboru i qpilismy HP. dodatkowo wybrałem architekturę AMD – więcej corów w mniejszej cenie daje większą elastyczność przy dystrybucji zasobów procesora na maszyny wirtualne.
  • niesamowite jest ile startują te HPki! trzeba czekać ok. 2min [SIC!] zanim w ogóle zacznie uruchamiać się BIOS. do tej porty wydawało mi się, że BIOS jest zawsze pierwsze – ale w tych serwerach jest coś, co się dzieje wcześniej. MASAKRA.
  • z AMD natomiast jest inny ból – Hyper-V nie chce działać, złośliwie mówiąc, że procesor nie wspiera wirtualizacji albo nie jest włączony DEP. okazuje się, że jest to spowodowane dodaniem do Opterownów z serii Buldozer technologii AVX. szczęśliwie jest na to poprawka: opis i download poprawki KB jest tutaj. pomimo, że technologia jest
    również w Intelach – poprawka jest tylko dla AMD. O_o
  • pozostaje kwestia konfiguracji jumboframes… na co najmniej oddzielny artykuł – to kolejna sprawa, która najczęściej podsumowywana jest ‘wystarczy włączyć’, a kiedy sprawę się ruszy okazuje się, że konfiguracja tego badziewia jest przytłaczająca i roi się wyjątków, wyjąteczków i wyjątusiów. wyjątusie są najgorsze q:
  • tak na prawdę to siedzę nad konfiguracją tego syfu 4 dzień i nadal mi nie działa – po uruchomieniu CSV w momencie, kiedy dwa serwery próbują coś pisać w tym samym czasie, całość przestaje działać. no i stąd mam za sobą kilkanaście artów na każdy temat. powinienem być mądrzejszy a czuję się głupszy. sprawę złożyłem we wsparciu Dell bp problem jest na pewno gdzieś na linii komunikacji z voluminem na macierzy… a więc na pewno będzie jeszcze krótkie podsumowanie dot. [za pewne jakiegoś głupiego] błędu jaki można zrobić podczas konfiguracji CSV..

eN.

system backupu na maszynie wirtualnej

scenariusz: chcemy zwirtualizaować serwer backupów.

problem: podstawowy problem to obsługa sterowników/urządzeń. oczywiście w przypadq backupu dyskowego nie ma problemów – mamy do dyspozycji kilka opcji. albo po prostu podłączenie dysq pass-through albo iSCSI. w przypadku napędu taśmowego nie jest tak łatwo. VMWare częściowo wspiera takie rozwiązania, pozwalając na bezpośrednie przekierowanie obsługi urządzenia do systemu guesta – nie mam w tej kwestii doświadczeń, poczytałem sobie tylko, że nie wszystko jest obsługiwane, ale szczegółów nie znam,

co w przypadku Hyper-V? jest bardziej uniwersalny sposób – iSCSI. tak, tak. nie służy tylko do dysków – przecież to pełna obsługa SCSI przez TCP/IP a więc czemu by nie opublikować urządzenia taśmowego po iSCSI?

zredefiniowany problem: jak znaleźć odpowiedni iSCSI Target? jest wiele darmowych produktów – choćby Microsoftowy – ale większość pozwala wyłącznie na tworzenie targetów do dysków wirtualnych. bardziej zaawansowane pozwalały na publikację plików ISO jako targety, fizycznych dysków etc. jednak ze znalezieniem takiego, który wspiera napędy taśmowe – był problem.

sięgnąłem po StarWinda – ponieważ to AFAIK najbardziej zaawansowany software iSCSI Target. nie myliłem się – w pełni obsługuje takie rozwiązanie. problem polega na tym, że pojedyncza licencja kosztuje ok. $1.ooo. to trochę dużo – zwłaszcza, że nie mam zamiaru wykorzystywać go do celu tworzenia wielkiego SANa, a tylko opublikować jedno urządzenie. q mojej uciesze na stronie z darmowymi produktami jest “Tape Redirector” – uproszczony iSCSI Target, stworzony właśnie w tym celu, i to za free!  

instalacja: aby zassać program trzeba mieć konto StarWind – weryfikacja danych jest na tyle niemiła, że nie przyjmuje nawet maila z publicznej skrzynki – musi to być konto korporacyjne. aplikacja instaluje się łatwo i przyjemnie i jest tak intuicyjna, że nie ma co się rozwodzić. jedyny problem – interfejs z jakiś powodów przekłamuje numer portu, dodając 1 – standardowy port tego targetu to 33268 a wszędzie pokazuje 33269.

image

po odpaleniu inicjatora po stronie systemu guesta i skonfigurowaniu połączenia, w urządzeniach pięknie pokazuje się odpowiednie urządzenie.

niespodzianką był komunikat podczas próby instalacji sterowników urządzenia na guescie, iż nie są wspierane w środowisq wirtualnym. szczęśliwie była również opcja ‘extract’ i po ręcznej instalacji samego sterownika, całość zahulała jak należy (: zresztą BE ma swoje własne sterowniki i niechętnie współpracuje z tymi dostarczanymi przez producenta – a więc najlepiej nie instalować!

na próbę zainstalowałem Backup Exec 2o12 w wersji trial. przetestowałem backup, inwentaryzację, restore – wydje się, że wszystko działa jak należy. można wirtualizować!

wydajność: to oczywiste, ale na wszelki wypadek – aby uzyskać odpowiednią wydajność rozwiązania należy odpowiednio skonfigurować środowisko wirtualne. karta sieciowa dla powinna być dedykowana dla rozwiązania. bez żadnej szczególnej konfiguracji miałem 93MBps.

eN.

łamanie haseł do wifi

AP cisco i d-linka implementują WPS – WiFi Protexted Setup. to taki dyngs dla lame-userów, który pozwala w przypadku zapomnienia hasła do sieci wpisać krótki PIN, i urządzenie wysyła hasło użytkownikowi [w skrócie]. są implementacje trochę bardziej bezpieczne – np. wymagają naciśnięcia jakiegoś guzika, albo po kilqkrotnym wpisaniu złego PINu blokują na jakiś czas, ale wiele urządzeń jest podatnych na ataki na owy PIN. co więcej – wystarczy wysłać tylko pierwsze 4 znaki PINu, żeby przekonać się czy jest nieprawidłowy.

dzięki temu nawet WiFi z uwierzytelnieniem WPA2 można złamać szybko i łatwo. narzędzie do tego celu nazywa się reaver.

eN.

OT: City Exploring

City Exploring to taka gra. kiedy się jest w nieznanym mieście można zwiedzać ciekawe miejsca … tylko co znaczy 'ciekawe’? muzea? ruiny? 'ważne’ budynki? i czy po takim zwiedzaniu odczuwa się prawdziwą atmosferę miasta? tajemnica klimatu kryje się nie tam gdzie są turyści [w takich miejscach atmosfera ma charakter mocno globalny q:] tylko w małych zakątkach, nieznanych uliczkach, wśród zwykłych ludzi – biegnących do pracy, odpoczywających w kawiarniach czy pubach, na obrzeżach miasta i w nieodwiedzanych częściach. w taki sposób można zwiedzać również własne miasto – zboczyć z głównych dróg, odciąć się od 'szlaków’ i trafić do innego świata.
zasady gry są proste:

  • nie używać map w żadnej postaci [chyba, że do samego zapisu i późniejszego odtworzenia, ale nie podczas 'rajdu’]
  • nie mieć konkretnego celu za to dysponować czasem
  • po prostu iść wybierając losowe kierunki – te trochę bardziej niepokojące, wąskie uliczki, przypadkowe zakręty. po prostu zobaczyć na horyzoncie coś ciekawego i spróbować tam dotrzeć. jeśli się zgłodnieje – poszukać jakiejś lokalnej speluny zamiast 5* restauracji. spróbować się zgubić – jesteśmy tak obładowani gadżetami [i codziennością], że za pewne większość nie pamięta nawet co znaczy 'zgubić się’. przemierzamy dobrze znane szlaki, albo ciągniemy się śladem GPSa, nie zastanawiając się nad otoczeniem, nie obserwując ludzi ani budynków. kiedy ostatnio czuła(e)ś dreszczyk emocji – 'czy wiem gdzie jestem?’. zaczyna się bacznie obserwować otoczenie, wypatrywać znaków szczególnych, obserwować położenie słońca/gwiazd – rzeczy, które nie tak dawno były oczywiste, dziś, w miejskich szczurach, wyeliminowane.
  • pozostaje wrócić do swojego habitatu – pamiętasz kierunek? jeśli potrzebujesz wskazówek – zapytaj kogoś. nie używaj map ani elektroniki. sprawdź reakcję ludzi – czy uda się dogadać? może czasem trzeba na migi, czasem używając bardzo podstawowych słów – ale jak inaczej przekonać jacy są ludzie w danym miejscu?

ryzykowne? być może miałem szczęście – ale nigdy nic mi się nie stało. zwiedzałem tak warszawską pragę w środku nocy, uliczki damaszku [podczas rewolucji q:], spałem na dworcu w wenecji i po jakiś zapyziałych dzielnicach paryża… ludzie okazywali się [prawie zawsze] pomocni [w najgorszym przypadku nieprzydatni (; ], skorzy do pomocy – często zupełnie nie znając języka gdzieś zaprowadzili, coś pokazali – to na prawdę przywraca wiarę 'w świat’ (:

wolę takie zwiedzanie-błąkanie, niż zaplanowane wycieczki od-pomnika-do-pomnika…

eN.