mRemoteNG

jednym z najlepszych programów zdalnego pulpitu był mRemote. był na tyle dobry, że kupił go wraz z programistą … eeee nie pamiętam nazwy firmy. obecnie produkt wyodrębniony jako projekt i nazywa się Royal TS. Cena nie jest z kosmosu – jedynie €25, więc dostępne niemal dla każdego.

jeśli jednak nadal poszuqjesz darmowej alternatywy – to postał fork mRemote – mRemoteNG. poprawiono w nim najważniesze problemy, jakie występowały w starej wersji.

czemu nie microsoftowy Remote Desktop Connection Manager? dla mnie najważniejsze cechy to:

  • obsługa wielu protokołów – nie tylko RDP
  • obsługa podkatalogów z dziedziczeniem – bardzo przydatne do grupowania połączeń przy dużej ilości serwerów. RDCM obsługuje katalogi, ale poza tym struktura jest płaska
  • lepsza obsługa focusa – RDCM jest piekielnie wkurzający w tej kwestii…
  • wiele, wiele więcej…

eN.

Wszechwiedzący user

nawiązując do głupich komunikatów w windows – było o IE, a teraz taka ciekawostka przy połączeniu WiFi na w8. łączę się do serwera i dostaję ostrzeżenie:

error1

jest ‘show details’! super. sprawdzę co to za cert żeby zdecydować:

error2

eeee /: no i wszystko jasne. teraz decyzja jest oczywista…

eN.

Szacunkowe wyniki sprzedaży Surface RT i Pro

Na Bloombergu ukazał się artykuł mówiący o szacunkowej sprzedaży Surface RT i Surface Pro – jest to o tyle ciekawe, że MS jak do tej pory nie opublikował żadnych danych odnośnie poziomu sprzedaży. Przechodząc do konkretów – wg źródeł Bloomberga od czasu premiery sprzedało się ok 1 mln Surface RT  i 400 tys sztuk Surface Pro.

Powyższe wartości są znacznie niższe od tego co szacował MS –  kilka różnych źródeł podawało, że wyprodukowano 3 mln Surface RT – czyli z tego wniosek, że 2 mln sztuk zalega na magazynach.

By te wartości miały swój kontekst – w 4Q 2012 sprzedano na całym świecie 52,5 mln tabletów z czego Apple sprzedało niecałe 23 mln.

Co więcej – w  2013 ma sprzedać się ok 200 mln tabletów (wzrost o blisko 50% rok do roku!). Również ten rok ma być pierwszym rokiem gdzie sprzeda się więcej tabletów niż notebooków.

Artykuł również nadmienia o sprzedaży notebooków w 1Q2013 – wyniki są…. słabe – sprzedaż notebooków  w 1Q2013 w porównaniu do 4Q2012 ma spaść (bo jeszcze kwartał nie zakończony) o 18% – licząc średnią z ostatnich 5 lat rok do roku jest to spadek o 9%

Cóż… era post PC in progress

 http://www.bloomberg.com/news/2013-03-14/microsoft-s-surface-tablet-is-said-to-fall-short-of-predictions.html

Hyper-v replication v1.o?

znaczenie wersji produktów/ficzerów w Microsoft:

  • v1.o – marketing czyli ‘mamy taki produkt, jesteśmy na rynq!’. w rzeczywistości nie zdatny do użytq – po prostu ładnie wygląda na reklamie i informuje, że eMeS wyraża zainteresowanie tym fragmentem rynku
  • v2.o – początek, czyli – ‘mamy taki a taki produkt, potrafi to i to, nie potrafi jeszcze tego i tego, ale SOHO/SMB ma już pewne funkcjonalności za free’. w rzeczywistości – hmmm.. faktycznie działa.
  • v3.o – wdrażamy w ENT. w rzeczywistości – można wdrażać w ENT, bo faktycznie już jest skalowalny i większość funkcji nie dość że jest, to działa dobrze.

w w12 jest PowerShell v3.o oraz Hyper-v v3.o – oba naprawdę fajne i dojrzałe. a do Hv dodano nową, świetną funkcjonalność – Hv Replication… i jest ona ewidentnie w v1.o.. no może v2.o. o samej konfiguracji już trochę pisałem. czas na opis samej funkcjonalności.

co można o niej powiedzieć – jest. pomysł zaiste przedni – na miarę VMWare SRM. do tego stopnia fajnie pomyślane, że pozwala na wykorzystanie w scenariuszu hostingowym, gdzie stacje nie są w tej samej domenie. zacnie. skoro backup na hostingu – to znaczy łącze jakieś-takie. w sensie, że nie LAN 1GB. i teraz dochodzimy do clue, czyli to, co w całej świetności zostało spartaczone do stopnia nieużywalności. a są to dwa podstawowe ‘mankamenty’ + jeszcze trochę:

  • miejsce docelowe replikacji ustawiane jest per cały cluster a nie per replikowana maszyna wirtualna.
  • replikacja wykonywana jest co 5 min. i nie inaczej.

konsekwencje:

– jeśli chce się zrobić replikę całego clustra Hv, to wszystkie maszyny pchane są na pojedynczy storage. nawet jeśli maszyny-źródła są rozlokowane na wielu CSV dla zwiększenia wydajności, to docelowo będą przechowywane na pojedynczym. czyli jeśli strzeli podstawowa serwerownia, to zapasowa i tak może nie unieść takiego obciążenia. w efekcie można stosować albo dla bardzo małych środowisk – jedna, dwie maszyny, albo dla bardzo bogatych – gdzie jest się w stanie dostarczyć infrastrukturę [macierz, switche, NIC etc] potrafiącą unieść ‘takie’ obciążenie na jedym CSV. ‘takie’ – testowaliśmy to myśląc o redundancji dla klienta, gdzie na źródlanym klastrze stoi ok. 4o produkcyjnych maszyn. jedynym ratunkiem jest dodatnie do naszego DRP kroku pod tytułem ‘storage migration’ – czyli w trakcie uruchamiania maszyn w naszej lokalizacji offsite, równolegle migrujemy je na inne/docelowe CSV. odpalenie 4o wirtualek na jednym CSV po prostu się nie uda.

– no i najgorsze z najgorszych – czyli te nieszczęsne 5 min. ktoś, kto to zaharcodował musiał być po ciężkiej nocy – nie wnikając czy chodzi o pracę, czy zabawę, ale na pewno miał zaćmienie. replikowane są oczywiście delty – super. Mierzyliśmy je i nawet przy produkcyjnej maszynie nie są to *standardowo* duże zmiany – ot, 2-4MB. nawet dla 4o maszyn, przy 1oMbps łączu – 5min [teoretycznie i przy pełnej przepustowości] powinno wystarczyć. ale często, zbyt często, na maszynach produkcyjnych pojawiają się zmiany dużo większe – transakcje sql przy operacjach maintenancowych, operacje na serwerze plików, gdzie wrzuca się duże wielości czy tymczasowe pliki zrzucane przez aplikacje. nieszczęsny DPM potrafi na chwilę wrzucić 5GB plik. nie ma niestety możliwości utworzenia wykluczenia dla katalogu czy typu pliq – co w jakiś sposób by zminimalizowało problem w związq z czym trochę matematyki:

  • załóżmy, że aplikacja utworzyła tempa 5GB. w sumie to bez większej różnicy czy jest to temp czy nie, ale ten scenariusz jest bardziej absurdalny i pokazuje nonsens w jaki się wpada, bo plik za chwilę znika. 5GB=4o96oMb. przy teoretycznym 1oo% dostępności, dajmy na to na 5oMb łączu, taki plik repliqje się 4o96o/5o/6o=13,65 minuty. tylko ta jedna zmiana i na naprawdę fajnym łączu i przy 1oo% dostępności – czyli warunki bardzo optymistyczne [czyt. mało realne]. dla 1oMb łącza ta liczba to już ponad 1h.
    co się dzieje w tym czasie? oczywiście uruchamiają się kolejne wyliczenia delty, ponieważ w ciągu tego czasu minęło kilka/wiele 5minutówek. w praktyce może się okazać, że za nim zreplikujemy naszą pierwszą zmianę (5GB) to przestanie ona być aktualna, ponieważ za chwile nadpisze ją kolejna zmiana. czyli w praktyce hv wysyła coś, co za chwilę zostanie nadpisane kolejną zmianą. zamiast się połapać i od razu wysłać ostatnią wersję naszych zmian. mały schemat:

image

jakieś tam obejście to zpauzowanie replikacji i uruchomienie z opcją resynchronizacji [koniecznie run as admin, inaczej krzyczy, że takiej maszyny nie ma]

  • Suspend-VMReplication –vmname <VNAME>
  • Resume-VMReplication –vmname <VNAME> -resynchronize

dzięki opcji resynchronize hv idzie po rozum do głowy i porównuje stan maszyny replikowanej na chwilę obecną z maszyną kopią, ergo tworzy nową deltę jedynie z ostatnimi zmianami. oszczędza nam to replikowanie ‘stanów pośrednich’. niestety resynchronizacja trochę zajmuje, dodatkowo została pisana z myślą o vhd/vhdx nie większych niż 500 GB. jeśli mamy takie trochę większe (np. dysk z danymi baz ponad 1TB), wtedy resynchronizacja zachowuje się mało wydajnie.

pojawia się wiele dodatkowych wątpliwości – bo trzeba nieźle się wstrzelić z czasem tegoż suspendu. w praktyce, wymagane jest małe dochodzenie, w jakich godzinach dochodzi do tworzenia ogromnych delt. osobiście pomogłem sobie małym skryptem, odpalanym ze schedulera co 5 minut

  • $time = "{0:yyyy-MM-dd_HH.mm.ss}" -f (get-date)
  • measure-vmreplication <VNAME> >> c:temp$time.txt

w prosty sposób mamy fajny obraz jak nasze delty rosną na przestrzeni czasu.

a rozwiązanie mogłoby być bardzo trywialne: zamiast nie-wiedzieć-skąd-wymuszone-5-min, wystarczyłoby, aby każda synchronizacja była wzbudzana – ot choćby przez scheduler. dzięki temu można byłoby w pełni kontrolować całą replikację, robić ją np. 2 razy dziennie, omijać okienka maintenancowe i backupowe i tak dalej…

z rzeczy na plus, które faktycznie działają i są miłym zaskoczeniem:

  • kompresja – pogłoski mówiły o superwydajnym rosyjskim algorytmie, ale nie wiadomo jak to jest w praktyce. wiadomo natomiast, że faktycznie działa. zależnie od pomyślności wiatrów skacze od 5o% do 7o%. przy wstępnych wyliczeniach można założyć, że mamy prędkość replikacji równą 1,5 przepustowości naszego łącza.
  • robienie pierwszej repliki na dysk USB – by zacząć replikację, musimy najpierw skopiować całą wirtualną maszynę do lokacji off-site. można to robić po WANie, ale można też tą pierwszą kopię zrobić na nośnik i przesłać go do serwerowni. kiedy nasza ‘initial replica’ zrobi się na dysk USB, po drugiej stronie powstaje replikowana maszyna z pustymi dyskami i snapshotem. Hv replikuje już zmiany do snapshota, mimo, że cała maszyna nie została jeszcze wgrana. replikacja działa, a kiedy kurier zawita do nas z nośnikiem, możemy w dowolnym momencie zaimportować sobie naszą pierwszą replikę.
  • wersjonowanie – czasami może się okazać,
    że replikujemy zmiany z już uszkodzonej wirtualnej maszyny. nasza replika jest odwzorowaniem oryginału 1:1, więc jeśli uszkodzi się OS w oryginalnej maszynie, to samo spotka naszą replikę. wersjonowanie umożliwia trzymanie kilku snapshotów replikowanej maszyny. gdyby okazało się, że coś nie hula, możemy cofnąć się o te kilka/kilkanaście godzin.

na chwilę obecną Hv replica jest i się uśmiecha, ale jest to jeszcze bardzo nieśmiały uśmiech. niemniej działa i przy świadomości ‘charakterystyki’ tego działania, można śmiało wdrożyć to dla klienta, który nie ma wyśrubowanych wymagań. w praktyce eMeS oferuje nam trzy opcje na stworzenia sobie taniego DRP:

  • Hv Replica
  • połączenie Hv Replica i Data Protection Manager Chain Backup – maszyny, których nie da się replikować Hv Replicą, replikujemy DPMem, który podobnie wylicza delty, ale w bardziej zarządzalny sposób.
  • DPM Chain Backp – wszystko replikowane za pomocą DPMa

każde podejście ma swoje zady i walety ale o tym… może kiedyś…

eN & Damian Skrzypiec