Deci.
In VMware Fusion, cat si in VMware Workstation pot instala VMware ESXi. Iar in ESXi-ul respectiv pot instala un alt ESXi. Si tot asa. Pentru ca se poate.
Din pacate Fusion nu suporta si instalare de Hyper-V, ca l-as fi inceptionat sa-i sara bitii. Linux in ESXi in Windows in Mac.
Dupa vreo cam vreo 3 saptamani asa de stat pe Mac e cam in felul urmator:
Cand ai de a face cu sisteme de stocare de tip SAN, dimensionarea acestora devine un pic mai interesanta in sensul ca trebuie luati in considerare mai multi factori, in functie de destinatia/destinatiile acelui sistem.
Pentru ca un SAN costa o caruta de bani si nu poti sa te duci sa-l schimbi cu altul mai mare sau mai frumos dupa 2 luni ca ti-a dat cu virgula prima oara, e bine sa stii de la inceput ce vrei.
Workload-ul pe un storage (SAN) poate fi de la cum facem sa avem un fileserver de 50TB pana la cum facem sa avem acces cat mai rapid la o baza de date de 3TB sau cum facem sa rulam de pe el 300 de masini virtuale care sunt folosite in diferite moduri.
In primul rand, trebuie evaluat cam cate IOPS (Input/Output Operations per Second) va trebuie sa suporte in mod sustinut sistemul de stocare. O operatie de citire reprezinta un IO, o operatie de scriere reprezinta un IO.
E foarte important de mentionat faptul ca IO nu are legatura cu rata de transfer in acest context. E posibil ca un singur disc sa poata citi cu 100MB/se si sa scrie cu 80MB/sec, insa asta se intampla doar daca se citesc/scriu date in mod secvential (de exemplu scrierea sau citirea unui fisier video de 100GB). Daca in schimb e nevoie de scris sau citit date aleator de pe disc, atunci rata de transfer poate ajunge la cativa MB si totul se va misca cu viteza melcului turbat.
Majoritatea producatorilor de software al carei performanta depinde de cat de rapid este sistemul de stocare ofera unelte prin care se pot estima numarul de IOPS-uri necesare pentru o functionare optima intr-un anume mediu de lucru.
De exemplu Exchange Server zice ca are nevoie in medie de cam 1-2 IOPS per utilizator, in conditiile in care utilizatorul primeste ~75 de mesaje si trimite 25. Daca ai 200 de utilizatori care se per total se incadreaza in aceasta medie, ai nevoie de un sistem de stocare care sa sustina 250 IOPS (am pus inca 50 pentru peak-uri).
Sa zicem ca mai avem nevoie ca acelasi SAN sa fie utilizat si de un server SQL care are nevoie de 500 IOPS in medie si cam de 700 in peak. Mai punem un filserver care are nevoie de 100 IOPS.
In total avem nevoie in medie de 250+500+100 = 850 IOPS in medie si cam 1050 IOPS in peak. Sa presupunem ca nu moare nimeni daca dureaza un query 20 de secunde in loc de 10 si sa zicem ca maximum cu tot ce avem nevoie sunt 1000 IOPS.
Al doilea lucru care trebuie luat in calcul, insa de obicei primul la care se gandeste toata lumea: capacitatea de stocare. Cate date poate stoca sistemul. Sa zicem ca in cazul asta e nevoie de 10TB de date (da, avem mailboxuri cu mult filmulete cu pisicute simpatice) si foarte multe poze si cateva baze de date mai maricele.
Acum, un SAN ofera si redundanta la date. Asta inseamna o matrice de tip RAID.
Iar ca lucrurile sa fie complicate, exista mai multe tipuri sau niveluri:
Pana acum avem ca si cerinte: 1000 IOPS si 10TB cpacitate.
Daca ne luam dupa Wikipedia, avem urmatoarele variante cand vorbim de hard disk-uri:
Daca as folosi RAID-0 as avea nevoie de (iau in considerare cel mai mic numar de IOPS):
Ce n-am calculat, e ce capacitate sa aiba un disc. Un disc S-ATA normal are acum cam 1TB capacitate la un cost foarte rezonabil. Asta inseamna ca pentru a satisface numarul de IOPS necesar, o sa am o matrice RAID de 14TB pentru 10TB spatiu util.
Daca vreau sa iau discuri SAS la 15K RPM, imi trebuie vreo 12 sa ajung la 10TB din motiv ca cel mai mare disc SAS la 15K RPM pe care il stiu are 900GB.
Daca sunt paranoic si zic vreau protectie maxima, atunci o sa aleg o matrice de tip RAID-6 (presupun ca n-am bani de o matrice de tip RAID60) o sa am nevoie de aproximativ 39 de discuri S-ATA de 7200RPM pentru a ajunge la cam 1000 IOPS.
39!
Daca iau in considerare discuri de 1TB, o sa am aproximativ 36TB capacitate. Astea toate pentru 1000 IOPS si 10TB.
Daca ma gandesc la cel mai rapid disc, SAS la 15K RPM, atunci o sa am nevoie de doar 17 discuri si 14TB spatiu (900GB per disc).
Calculele de mai sus sunt facute in ideea in care avem 50% scrieri si 50% citiri. Si ca nu exista cache nicaieri.
Financiar vorbind, capacitatea e ieftina, IOPS-urile reprezinta cel mai mare cost.
Pentru a alevia o parte din probleme, toti producatorii de sisteme de stocare de tip SAN au memorie cache dedicata pentru controllere pentru a stoca datele cel mai de accesate si a mai lasa discurilor ceva “timp sa respire” intre scrieri si citiri.
Memoria cache e de obicei intre 1GB si 32/64GB, insa costa pe masura si nu poti pune 64GB cache in orice fel de sistem.
Mai nou (adica de vreo 1-2 ani asa), exista posibilitatea de a folosi discuri SSD ca si nivel de intermediar de cache.
Servere <-> memorie cache SAN <-> SSD <-> matrice RAID.
Asta inseamna ca poti avea unul sau mai multe SSD-uri de cativa zeci/sute GB care pot prelua valul de date si le pot tine pana cand discurile mai lente apuca sa le scrie. Un disc de tip SSD recent poate duce cam 50-80.000 IOPS fara probleme.
Si atunci intrebarea ar fi: de ce nu punem discuri SSD peste tot si nu mai batem capul cu IOPS-urile ? Pentru ca discurile SSD de tip Enterprise sunt inca foarte scumpe, de exemplu un disc de 400GB costa intre 4000 si 9000EUR in functie de producator si tehnologia folosita: SLC sau MLC. Si o sa devina interesant de explicat de ce vrei sa dai 100.000EUR pe 10TB de spatiu.
Ca si concluzie, in primul rand trebuie aflat care e necesarul de IOPS, in al doilea rand de ce capacitate e nevoie si in ultimul rand de ce tip de matrice RAID e necesara pentru protectia datelor (RAID nu inseamna backup, insa dormi mai linistit cu cat minimizezi sansele de a pierde date chiar daca pierzi un numar semnificativ de discuri).
M-am gandit sa scriu postul asta pentru ca am tot avut de a face cu oameni care se gandesc la capacitate si iau SAN-ul cu discuri S-ATA si dupa aia dau vina pe producator ca le merge de sta.
Oficial am trecut pe Mac.
Mai am ceva dileme cu obisnuirea si cu shortcut-urile si aplicatiile, da sunt pe drumul cel bun.
Initial voiam sa numesc postul “primul post de pe mac mac”, da’ parca suna asa… ne-natural.
Acu ceva vreme am zis sa renunt la ym/msn si sa ma dau pe gtalk (mai mult din cauza ca incepuse sa-mi displaca pidgin fara un motiv anume). Client mic, mergea calumea si pentru instant messenging era tot ce-mi doream.
Pana la un moment dat in care cineva de la Google s-a scarpinat adanc in cur si a zis ca gata, GTalk nu mai e trendy hai sa punem pe toata lumea sa foloseasca Google Hangouts. Dupa inca o alta scarpinatura in cur cu mana pana la cot, altcineva probabil si-a dat cu parerea ca ar fi bine sa nu faca un client de desktop si totul sa se intample in browser. Ca memoria e ieftina si ai mereu deschise cateva ferestre intr-un browser, ce mai conteaza una-doua in plus, nu ?
Foloseam GTalk pe telefon si bineinteles ca a trebuit sa imi pun Hangouts. Care cel putin pe iPhone (nu stiu restu cum sunt) e o mizerie crunta. Cred ca si daca aplicatia era scrisa de un student repetent nu era asa proasta: notificari aiurea, se misca greu de parca la fiecare apel de system mai are si un sleep() ascuns acolo. Imi apar notificarile cand vrea muschiu lui, nu face clear la ele chiar daca vad mesajele etc.
Si uite asa ieri mi-am bagat peula in el. Ca a intrat la exemple de cum sa futi o aplicatie lightweight si functionala si sa o inlocuiesti cu ceva bloated si abia functional. Go Gugle!
Azi s-a intamplat perfect shitstorm-ul in materie de cum sa-ti crape toate o data.
Un port dintr-un switch de FC a decis sa se duca pulii de suflet si sa genereze erori si intarzieri. Asta s-a transmis spre un cluster de VMware ca are latente la accesul la disk si a inceput sa initieze tot felul de mutari de masini virtuale astfel incat sa nu mai aiba probleme.
Care au pus si mai mult stres pe duda aia de port, ca intr-un final tot clusterul sa devina suficient de instatabil incat nimic sa nu mai mearga. Si toate request-urile de I/O sa se duca cumva fix pe portul stricat, ca altfel nu se putea.
Pana n-am oprit totul si am inceput sa le pornesc pe rand pana s-a stabilizat treaba nu s-a putut face nimic.
Si peste toate astea, s-a futut si timpul de pe masinile virtuale si nu mai mergea autentificarea in domeniu. Pe langa asta nu mai porneau nici servicii care erau legate de Active Directory si tot asa.
Dupa inca un rand e reboot-uri, totul si-a revenit la normal.
Ocazie cu care trebui sa-mi accelerez planurile pentru o modificare de design astfel incat daca se mai intampla chestii din astea, sa pot sa ma leg remote sa le repar.
Si cred ca un switch e pe cale sa ia drumul RMA-ului, ca totul pare OK, mai putin cand vreau sa trec trafic printr-un port anume prin el.
Ma gandeam io zilele trecute cum faci sa nu se mai uite toti taranii in traficul tau si mi-a venit in cap o idee de business. Da cum n-am bani, o s-o zic aci, poate citeste careva si face un ban cinstit.
Eu ma asteptam ca se uita unii si altii in ce mai face lumea pe internet, dar nu ma asteptam sa se uite chiar in tot. Si asta ma enerveaza, nu c’ar fi secret ce scriu pe facebook sau pe blog, da mi se pare de cacat sa fiu spionat non-stop.
Si io ca io, ca astia de spioneaza ciordesc informatiile care li se pare utile si le dau la ai lor sa le foloseasca in scopuri comerciale. Contracte, mailuri confidentiale si alte cele.
Super planul: oferirea unui serviciu de VPN de tip Hub & Spoke intre companii. Deja exista implementata treaba asta in companii (in alea cu multe branch-uri), acum nu trebuie decat facuta intre companii.
Cum functioneaza treaba: un 3rd party face tunele IPSec cu cei interesati de securitate. Tunelul este doar intre gateway-uri. peste acest tunel “point-to-point” se baga GRE si peste GRE faci un mic OSPF/BGP in care clientul isi anunta ce e ar trebui protejat la el (sa zicem subnetul definit ca DMZ ca ala de obicei are adrese IP publice).
Un al doilea client face acelasi lucru, al treilea la fel si tot asa. Si primesc inapoi de la fiecare ce prefixe trebuie rutate peste VPN.
Daca ajungi la o masa critica, atunci pentru business, internetul nu este decat o teava opaca pentru taranii care vor sa se uite in trafic dupa informatii pe care sa le poata folosi in scopuri nu tocmai utile sau legale.
Avantajul la un setup din asta e ca si daca una din companiile care participa in acest super Hub & Spoke e una sub acoperire a unei agentii de spionaj e degeaba, ca tot ce primeste sunt niste prefixe, nimic mai mult, nu poate trimite trafic aiurea sau sa primeasca trafic care nu trebuie.
Dezavantajul tehnic la jucaria asta e ca o sa ai foarte multe prefixe in tabela de rutare.
In toata ideea asta exista doua challenge-uri non-tehnice:
Tunelele sunt create cu certificate digitale, iar 3rd party pune la dispozitia clientilor o autoritate de certificare cu care doar semneaza CSR-urile, astfel incat sa nu existe suspiciune ca poate folosi in vreun fel cheile private pentru alt ceva. Si evident PFS activat la IPSec.
Singura premisa e ca NSA sau alta agentie de spionaj n-a gasit cum sa decripteze AES.
Cateodata imi vine sa-i bat cu levierul in dinti pe aia de la Microsoft:
Cum sa faci un service pack care iti ia o zi sa-l instalezi ?
Cam asa arata internetul intr-o tara care foloseste multe, multe proxy-uri sa blocheze tot felul de chestii nedorite de guvern. Si cand ai doi provideri de internet detinuti de mai mult sau mai putin de un singur grup de oameni inruditi :)
… e prost si exagerat de scump.
Da sa incep cu inceputul: daca vrei internet, te duci sa semnezi contract cu ce operator vrei tu, ca oricum primesti doar DSL care e pe infrastructura lui Deutsche Telekom si merge dupa cum ai norocol de zona. De la prost la foarte prost.
Unde stau acu, cea mai buna viteza de o poti avea este 16Mbps/1Mbps (down/up). A durat o luna si un pic pana s-a facut instalarea efectiva. Care instalare a constat in vizita unui om de le Telekom (ca asa se zice la ei, ca deja sunt germani…) sa lege doua cacaturi de fire la alte doua cacaturi de fire si uite asa sa ajungi pana la un DLSAM.
Modemul DSL a venit cu instructiuni din alea de configurare din 3 pasi: bagat in priza, conectat sarma de DSL, bagat user/pass si gata. Ai internet. Dar nu. Ca dupa ce a venit ala, a mai durat cateva ore pana cand cineva probabil a mai butonat ceva in DLSAM/BRAS sa ajunga conexiunea la providerul ales, in cazul asta 1&1. Care zice lumea ca e cel mai bun dintre toate ofertele proaste pe care le ai la dispozitie.
Setup modem: 20min (pana am gasit plicul cu user si parola).
Legat doua fire: o luna si un pic.
Treaba asta se intampla vineri, undeva pe dupa-masa a mers internetul. Pana luni dupa-masa. Dupa care pula.
Noroc cu prieteni nemti care sa sune la suport, ca astia engleza nu prea sprechanesc deloc, doar asa prin restaurante ca-ti vor banii. Dupa nenumarate apeluri la suport, se pare ca vineri o sa vina cineva sa vada ce si cum si dupa aia mai vedem. Pentru ca desi linia e sincronizata in DLSAM, se pare ca nimeni nu e capabil sa spuna de ce mortii lor nu se autentifica modemul sa am internet.
Si vineri se uita lumea, nu inseamna ca o sa si fixeze, desi io sper.
Si acu cu internetul: pentru doar 20EUR luna primesti 16Mbps/1Mbps cu limita la maxim 100GB pe luna. Care s-ar putea micsora daca isi pune DTAG mintea ca vor sa-i lasa pe prosti doar cu 75GB pe luna, ca e mai ieftin sa vinzi conexiuni limitate decat sa investesti infrastructura.
La jumatatea anului 2013 in Germania, cea mai jmechera tara din UE, situatia cu internetul e cam cum era prin Romania in 1998-2000 cand Romtelecom avea monopol si se pisa pe toata lumea. Numai ca la astia e mai rau ca nu ii lasa nimeni pe altii sa-si faca retele de comunicatii separate. Doar DTAG are voie.
Postul asta il scriu de pe laptop care e lagat la un telefon cu cartela prepaid de date care la care platesc 15EUR/1GB. de date. Si doar seara si un pic dimineata, ca in timpul zilei e cu treaba plecat telefonul :(
Si uite asa ma plimba ca vita prin Berlin toata ziua fara vre-un scop anume, neputand sa fac nimic util pentru ca asa e cand e monopol: se fixeaza problemele cand vrea pula alora care au monopol. Si nu se grabeste nimeni, ma mir cum de inca n-au facut reclamatie ca-i deranjam de prea multe ori cu telefoanele sa-i intrebam cand mortii lor au de gand sa fixeze problema.
DTAG = Deutsche Telekom = Telekom pentru evitarea confuziilor.