”LAN/SAN konszolidáció, ahogy azt ma látjuk …”

“A 2009-ben szabványosított FCoE (Fibre Channel over Ethernet) protokoll és az erre alapozott egységes adatközponti hálózat modell (Unified Fabric vagy I/O konszolidáció) megosztotta az IT társadalmat. Van aki üdvözli, van aki ellenzi és olyan is van aki csak érdeklődik és kivár. Megvalósulhat-e az egységes hálózat az adatközpontban, vagy marad minden a régiben? Ha igen, mely körülmények segítik elő a paradigma váltást, ellenkező esetben melyek a gátló tényezők?”

A múlt hónapban volt szerencsém (a fent idézett címen és témában) előadást tartani a Cisco Connect 2013 rendezvényen, ahol ígéretet tettem a hallgatóságnak, az előadás lényegi részének blogon való publikálásában. Mivel az előadás időkerete igencsak feszített tempót diktált, jó néhány tervezett gondolat kimaradt, ezért úgy döntöttem, hogy a lényegi pontok száraz publikálása helyett, inkább egy kibővített verziót vetek elektronikus papírra. Előrebocsájtom, hogy a bejegyzés terjedelmes lesz és foltokban mélyenszántó, ezért  külön köszönetet érdemel, aki türelmesen végigolvassa, de a lényegi összefüggések megértéséhez szükségesnek tartom a teljes gondolati ív bejárását.

Bevezető – Az általános helyzet:

Napjaink adatközponti infrastruktúrájában két különálló hálózat biztosítja a szükséges kommunikációs igényeket:

  • LAN hálózat: kliens – szerver, szerver – szerver kommunikáció, tipikusan Ethernet feletti IP protokoll segítségével
  • SAN hálózat: szerver – tároló (storage) kommunikáció, tipikusan Fibre Channel (továbbiakban FC) feletti SCSI protokoll segítségével

A LAN hálózat topológiája hierarchikus kialakítású (access-distribution-core), de az adatközpontban jellemzően csak az első két réteg van jelen (Collapsed Core Design). Az disztribúciós réteg aktív eszközei redundáns módon kapcsolódnak egymáshoz, illetve a hozzáférési réteg aktív eszközei szintén redundáns módon kapcsolódnak a disztribúciós réteghez. Mivel a L2-es hálózatnak hurokmentesnek kell lennie, a redundáns kapcsolatok miatt kialakuló hurok feloldásáról jellemzően a Spanning Tree Protocol gondoskodik, oly módon, hogy a kapcsolatok egy részét blokkolja, meggátolja a redundáns kapcsolatok aktív-aktív módú használatát a kommunikációban. Ugyan léteznek olyan megoldások is, melyben a kapcsolatok aktív-aktív módú használata biztosított (pl. LAG, MLAG/MC-LAG), de az általánosítás miatt, most erre nem térnék ki. A hagyományos Ethernet hálózat működési modellje “best-effort” jellegű, a pillanatnyi nagy adatforgalom miatt fellépő torlódás esetén (puffer túlcsordulás), egyes keretek eldobásra kerülnek. Az alkalmazások adatkommunikációja jellemzően IP(TCP/UDP) protokollon keresztül történik, ezért a TCP-t használó alkalmazások esetén maga a TCP flow-control mechanizmusa, míg az UDP-t használók esetén maga az alkalmazás gondoskodik az elveszett csomagok újraküldésének biztosításáról.

A SAN hálózat topológiája, a magas rendelkezésre állás biztosítása miatt, két fizikailag elkülönült hálózatból áll (úgynevezett “légréses” SAN Fabric), melyekhez úgy a szerverek (Initiator), mint a tárolók (Target) redundáns módon kapcsolódnak és az így rendelkezésre álló redundáns útvonalakat, a kommunikációra aktív-aktív módban használják (Multipathing). Mivel a SAN hálózaton futó alkalmazás (a blokk szintű írás/olvasást biztosító SCSI protokoll) nem tolerálja a csomagvesztést, ezért a vesztesség mentes adattovábbítást a FC hálózatnak kell biztosítani (Buffer to Buffer Credit).

hagyomanyos_dc

Költséghatékonysági szempontból jogosan merülhet fel az a kérdés, hogy a párhuzamos hálózatokon folyó alkalmazások kommunikációit, miért is ne lehetne egy egységes adatközponti hálózati infrastruktúrán kiszolgálni, oly módon, hogy az alkalmazások ezen változtatás hatására ne szenvedjenek el semmilyen hátrányt.

A vízió:

Project California (CA – Computer Array) – néven futott a Cisco UCS blade szerver rendszerének kifejlesztésre indított projekt, mely inkubációs idejét nem is a Cisco berkein belül, hanem (némi tőkével megtámogatva) kihelyezetten, a Nuova Systems nevezetű “startup” cég keretein belül töltötte. Ugyancsak a Nuova Systems volt a Nexus 5k/2k termékcsalád bölcsője is, ahol a hardverfejlesztés történt és a Cisco biztosította az adatközponti termékportfólió egységes operációs rendszerét (NX-OS). A kitűzött fejlesztési irányelvek igyekeztek optimálisabb megoldást biztosítani mindazon problémákra, melyekkel az napjaink adatközpontjai szembesülnek:

  • Zöld szemlélet – hatékony energia és helygazdálkodás
  • Fizikai értelemben vett  szerver konszolidáció
  • Virtualizáció – logikai szerver konszolidáció
  • Egységes (konvergens) adatközponti hálózat
  • Disaster Recovery

A fenti irányelvek közül csak egyet emelnék ki (a téma szempontjából relevánsat) az egységes (konvergens) adatközponti hálózatot, mely Unified Fabric vagy I/O konszolidáció név alatt alapvetően az egységes adatközponti hálózaton megvalósított LAN/SAN kommunikációt értjük.

A Unified Fabric vízió szerint a LAN/SAN konszolidáció adaptációja több fázisban fog megtörténni:

  • Az 1-es fázis a hozzáférési réteget tűzi ki célul, melyben a szerverek IO kapcsolatai, a hozzáférési réteg aktív eszközei, valamint az eszek közötti kábelezés kerül konszolidálásra. A szerverek hagyományos IO kapcsolatait (NIC/HBA) úgynevezett konvergens adapterek váltják le (CNA – Converged Network Adapter), melyek egy fizikai rétegen (10GE) képesek biztosítani mindkét alkalmazás kommunikációs igényeit, a hozzáférési réteg LAN/SAN aktív eszközeit pedig olyan aktív eszközök, melyek mindkét hagyományos hálózaton megvalósuló kommunikációt képesek kiszolgálni.

uf_phase_1

  • A második fázis ezen egy kicsit túlmutat, opcióként biztosítja a SAN hálózaton futó alkalmazás (Initiator –Target kommunikáció) End-to-End (továbbiakban E2E) kommunikációjának biztosítását a konvergens hálózaton.

uf_phase_2

  • A harmadik fázis az egységes konvergens hálózatot tűzi ki célul, melyen az alkalmazások az összes rendelkezésre álló fizikai kapcsolat egyidejű kihasználását és az ezáltal biztosított sávszélesség többletet képesek igénybe venni.

uf_phase_3

 

A háttér:

A vízió hátterében a 2009-ben szabványosított FCoE (Fibre Channel over Ethernet, T11 FC-BB-5) protokoll áll, mely nem más, mint egy újabb enkapszuláció (ezúttal FC kereteket visz át Ethernet fölött), mely lehetővé teszi a SAN hálózaton alkalmazott FC protokoll (FCP) és a fölötte futó SCSI protokoll kommunikációs igényeinek biztosítását Ethernet hálózaton keresztül.imageAnélkül, hogy belemennénk túl mélyen a részletekbe, látható, hogy a FCoE egy úgynevezett „Lossless Ethernet” meglétét feltételezi, mely nem azonos a hagyományos Ethernettel. A “Lossless Ethernet” megnevezés mögött, a hagyományos Ethernet továbbfejlesztését, új funkciókkal való kiterjesztését értjük, mely feladatot az IEEE Data Center Bridging (továbbiakban DBC) munkacsoportja vette gondozásba és szabványosította, az alábbiak szerint:

  • IEEE802.1QbbPriority-based Flow Control (továbbiakban PFC) – (2011)
  • IEEE802.1QazEnhanced Transmission Selection (továbbiakban ETS), Data Center Bridging eXchange ( továbbiakban DCBX) – (2011)
  • IEEE802.1QauCongestion Notification (2010)
  • IEEE802.1BRBridge Port Extension (korábban IEEE802.1Qbh) – (2011)

Az FCoE szabvány a fentiek közül csak az első kettőre tér ki, mint szükséges feltétel, ugyanakkor előírja dinamikus ACL-ek (Access Control List) használatát, melyek szükségességére még a későbbiekben kitérek.

De hogyan lesz az Ethernet vesztesség mentes?

Mint már a bevezetőben is említettem, a FC hálózat vesztesség mentes adatkommunikációját a Buffer to Buffer Credit (továbbiakban B2BC) flow-control mechanizmus biztosítja, mely két szomszédos eszköz közötti kapcsolaton fejti ki hatását, az alábbiak szerint:

A kapcsolat felépülésekor a két szomszédos aktív eszköz értesíti egymást (szinkronizál) a rendelkezésre álló puffer méretéről, ezáltal az adó fél mindig pontosan tudja, hogy a fogadó fél mekkora mennyiségű adatot képes feldolgozni, továbbítani, ezért csak addig forgalmaz adatot, ameddig van szabad puffer kapacitás a túloldalon. A fogadó fél értesítést küld az adónak amennyiben felszabadult egy puffer egység (R_RDY – Receive Ready), így folytatódhat a kommunikáció.

image

Az Ethernet is rendelkezik flow-control mechanizmussal (IEEE802.3x Pause), de az különbözik a B2BC-től. Ethernet esetén az adó fél addig ad, amíg a vevő vissza nem jelez egy Pause(időtartam) kontrol kerettel, mely következtében az adó, a Pause keretben lévő időtartam erejéig megszakítja az adatforgalmazást. Szükség esetén a vevő újabb Pause keret segítségével képes meghosszabbítani az adatkommunikáció szüneteltetését, illetve Pause(0) keret küldésével fel tudja oldani azt.

image

A kérdés csak az, hogy a vevő mikor küldje el a Pause keretet, ahhoz, hogy az optimális időben megérkezzen az adóhoz, hisz amennyiben az túl korán kerül elküldésre, úgy kihatással lesz a a vonal sávszélességének optimális kihasználására, illetve ha túl későn, akkor fennáll annak a kockázata, hogy a Pause keret megérkezésekor az adat már a vonalon van és a vevő, puffer kapacitás hiányában kénytelen lesz eldobálni a kereteket. Tehát a Pause keret elküldésének időzítése kulcs fontosságú, mely időzítés a puffer méret, az alkalmazott MTU és a távolság függvénye. Amennyiben az új generációs adatközponti hálózati eszközök adatlapjainak böngészésekor azt olvassák, hogy a 10 GE-s  FCoE-t támogató Ethernet kapcsolatok 300 m, 3 km, 10 km stb. távolságon támogatottak, gondoljanak a fenti időzítési problémára, az adott eszközök csak ezen távolságok áthidalására lettek hitelesítve/tesztelve.

Data Center Bridging fejlesztések:

  • PFC (IEEE802.1Qbb – Priority-based Flow Control) gyakorlatilag nem más, mint a 802.3x Pause mechanizmus kiterjesztése a 802.1p által definiált 8 forgalmi osztályra, mely segítségével megkülönböztetett kezelésben részesíthető a vesztesség mentes üzemmódot igénylő protokoll (esetünkben a SCSI parancsokat szállító FC).

image

  • ETS (IEEE802.1Qaz – Enhanced Transmission Selection) L2-es sávszélesség menedzsment mechanizmus, mely biztosítja a különböző forgalmi osztályok számára beállított, dedikált sávszélességet, ugyanakkor lehetőséget nyújt arra, hogy egy adott forgalmi osztály képes legyen dinamikus módon kihasználni egy másik forgalmi osztály által szabadon hagyott kapacitást. Ha analógiával élhetek akkor az ETS a L3-as CBWFQ (Class Based Weighted Fair Queuing)-nak megfelelő L2-es mechanizmus.

image

  • DCBX (IEEE802.1Qaz – Data Center Bridging eXchange) LLDP kiterjesztés, mely segítségével a szomszédos eszközök megbeszélik egymás között a  kapcsolaton alkalmazandó beállításokat, paramétereket (PFC, ETS, torlódás menedzsment, alkalmazás prioritás stb.)

image

Mint látható, a fenti funkciók biztosítják, hogy:

  • a közös fizikai médián át lehessen vinni különböző kommunikációs igényekkel rendelkező alkalmazások forgalmát
  • a különböző forgalmi osztályok (alkalmazások) képesek legyenek optimálisan kihasználni a rendelkezésre álló sávszélességet
  • a konvergens infrastruktúrát biztosító hálózati eszközök képesek legyenek egymás között kommunikálni és dinamikusan megbeszélni és alkalmazni az alkalmazások által igényelt beállításokat, paramétereket.

De mondhatjuk-e azt egy eszközről, mely támogatja a fenti három DCB kiterjesztést, hogy az FCoE kompatibilis?

Még mielőtt válaszolnék a fenti kérdésre, be kell vezetnem két új fogalmat. Az FC-BB-5 szabvány két protokollt is definiál:

  • FIP (FCoE Initialization Protocol) – a kapcsolat (Initiator és Target közötti session) felépítésért és fenntartásáért felelős kontroll protokoll (Control Plane)
  • FCoE – a SCSI forgalom továbbításáért felelős protokoll (Data Plane)

Az FCoE kommunikációt megelőzően,  a FIP protokoll segítségével fel kell építeni a kommunikáló felek közötti kapcsolatot és csak ezt követően indulhat meg az adatforgalom. A fenti három DCB kiterjesztés ugyan biztosítja a “jóhiszemű” felhasználást, de semmilyen biztonsági funkciót nem támogat, mely segítségével védekezni lehetne egy (pl. az FCoE VLAN-t célzó DoS) támadás ellen.

Tehát a fenti kérdésre a válasz nemleges. Ahhoz, hogy az eszközök a szabvány szerinti FCoE kommunikációnak megfeleljenek, támogatniuk kell egy FIP Snooping-nak nevezett biztonsági funkciót is, mely segítségével az eszközök dinamikus ACL-eket helyeznek el az interfészeken, figyelik a forgalmat és mindaddig nem engedélyezik az FCoE VLAN-ban való kommunikációt, míg az adott interfészen nem észlelnek egy szabályos FIP kapcsolat felépítést, mely alapján frissítik az ACL-ek összetételét azon engedélyező sorokkal, melyek a FIP protokoll által felépített kapcsolat kommunikációjához szükségesek.

Az FCoE protokollt támogató eszközöknek két típusa van:

  • FSBFIP Snooping Bridges – ezek azok az eszközök, melyek megfelelnek a fenti feltételeknek (PFC, ETS, DCBX, Dynamic ACL – FIP Snooping)
  • FCFFibre Channel Forwarder – ezek olyan FSB eszközök, melyek az alap feltételeken túlmenően további szolgáltatásokat is biztosítanak, mint az FC protokoll stack ismerete, FC szolgáltatások biztosítása (Name Server, Zoning stb.)

Adaptációs nehézségek, félelmek:

A víziót bevezető marketing kampányban elhangzott egy optimista jóslat, mely azt prognosztizálta, hogy az adaptáció 2-3 éven belül olyan méreteket ölt, hogy akár megvalósulhat a Unified Fabric harmadik fázisa és az adatközponti hálózat egységesen Ethernet alapú lesz … de nem így történt. Okolhatnánk a gazdasági válságot, mely nagyságrendileg egybeesett a bevezetéssel, de nem pusztán ennek hatása miatt nem vált valóvá a prognózis.

Nézzük sorban, hogy milyen adaptációs nehézségekkel találkoztunk ez elmúlt években:

  • Gyártók által keltett félelem, bizonytalanság (FUD)
    A Cisco a Unified Fabric modell terjesztésével egyidejűleg lépett be a szerver piacra, mely lépés nyilvánvalóan nem talált baráti fogadtatásra a piacukat védő konkurencia szemében, emellett maga a modell is, a SAN hálózatot alkotó FC switch-ek létjogosultságának megkérdőjelezésével borzolta a kedélyeket. Ennek hatására a kezdetben nagyon sok támadás érte magát a modellt, mely elbizonytalanította a technológia korai implementációjában érdekelteket.
    Időközben a gyártók fejlesztéssel, vagy akvizíciók segítségével kompetenciát építettek (HP – 3Com/H3C, Dell – Force10 stb.) és ma már elmondhatjuk, hogy szinte minden gyártó kínál megoldást az egységes adatközponti hálózat kialakításához, de azt is, hogy nem mindenki Ethernet alapon gondolkodik (pl. Oracle – Xsigo).
  • Lassú szabványosítási folyamat
    Bár a FCoE protokoll szabványosítása 2009-ben befejeződött, a DBC kiterjesztések szabványosítási folyamata egészen 2011-ig elhúzódott, ami azzal a kockázattal járt a korai implementálók számára, hogy a szabványok hiányában gyártó specifikus vagy pre-standard megoldáson alapuló konvergens hálózat, hosszútávon az adott gyártóhoz köti őket.
    Ma már a technológia minden szükséges komponense szabványos, csak arra kell figyelni, hogy implementálásra kiválasztott eszközök valóban feleljenek meg minden elvárt funkciónak és ne csak “papír” legyen róla.
  • Műszaki blokkolás – tipikus kijelentések:

Az Ethernet egyszerűen nem alkalmas …” és valóban, a hagyományos Ethernet nem, de a DBC kiterjesztéseket támogató új adatközponti Ethernet igen.

Etherneten magas a Bit Error Rate …”, mely kijelentés csak akkor igaz, ha hagyományos rezes kábelezést (CAT6a-7) kábelezést alkalmazunk, ugyanakkor optikai és speciális rezes (Twinax) kábelek használata esetén esetén megfelel az elvárt 10-18-as BER értéknek.

A SAN hálózaton a Storage gyártó diktál …”, mely kijelentés nyilvánvalóan az E2E kompatibilitást hivatott kihangsúlyozni. Szerencsére a gyártók gőzerővel dolgoznak a lehetséges forgatókönyvek tesztelésével, illetve a kompatibilitási listák bővítésével.

A “légréses fabric” megszűnése következtében a rendelkezésre állás csökkenni fog …” – kétségtelen, hogy az egységes adatközponti hálózaton, már nem lehet fenntartani valós fizikai szeparációt a két FC fabric között, ugyanakkor gondos tervezéssel logikai szintű szeparáció nem csak, hogy megvalósítható, hanem ez a legjobb gyakorlat is (a két fabric-nek megfelelő FCoE VLAN nem “keresztezheti” egymás útját egyetlen fizikai eszközön sem). A rendelkezésre állás csökkenése itt igazából arra utal, hogy a fizikai szeparáció hiányában, egyes “anomáliák” átterjedhetnek ez egyik eszközről a másikra és sérülhet a redundancia. A VLAN-ok megjelenése óta örök vitatéma, hogy elegendő-e a logikai szegmentáció, vagy a valós fizikai az elvárt bizonyos esetekben. Ebben a kérdésben nem lehet általánosítani, mindig az adott rendszerre jellemző paraméterek (biztonság, kritikusság) függvényében mérlegeljenek és hozzák meg döntéseiket.

Az egységes infrastruktúrán megvalósított rendszer bonyolultabb lesz …”, mely kijelentés természetesen igaz, de ugyanez elmondható a szerver virtualizáció esetén is, mégis azt látjuk, hogy a rendszerek igen magas százaléka napjainkban már virtuális környezetben fut.

  • Szakmaféltés
    Kétségtelenül ez az egyik legerősebb blokkoló tényező, mely alapvető emberi tulajdonságon alapszik. A SAN adminisztrátorok jogosan gondolhatják azt, hogy egységes hálózat alkalmazása esetén (lévén, hogy Ethernet alapú) nem lesz szükség a szaktudásukra, mely gondolat alapvetően hibás. A LAN adminisztrátorok nem komfortosak a SAN világában, ezért sokkal inkább egy új szemléletre van szükség, egy egységes adatközponti hálózat üzemeltető csapatra, mely a két világkép (LAN/SAN) összefonódásával alakulna ki. A cél ugyan az egységes hálózat üzemeltetése, de a szerepkörre osztott funkciók különbözőek és ezek logikai elválasztására most is van lehetőség Role Based Access Control (RBAC) segítségével.

Hol tartunk most?

A jelenlegi FC-BB-5 szabvány szerinti kommunikációban (mely lefedi a Unified Fabric modell 1-2-es fázisait) nem támogatott az FCoE initiator és target direkt kábelen vagy FSB-n keresztüli kommunikációja, a kapcsolatnak kötelezően egy FCF-en keresztül kell megvalósulni.

 

 

 

 

 

Ezt azért is fontos megjegyezni, mert jelenleg csak a Cisco és a Brocade gyárt FCF típusú eszközöket!

A modellnek megfelelő éles rendszerek üzemelnek:

  • Minden Cisco UCS blade rendszer natívan ezt használja
    (pl. a T-Systems Hosted Unified Communication szolgáltatása is ilyen rendszer fut)
  • Van éles ügyfél installációnk CNA kártyás rack szerverekkel
    (N5K, HP szerver, CNA, EMC tároló)

Állandó jelleggel elérhető demó környezet:

  • E2E FCoE demó környezet a T-Systems FutureZone innovációs központban (Cisco UCS blade – N5k (FCF) – EMC tároló, illetve rack szerver CNA kártyával – N5k (FCF) – N5K (FCF) – EMC tároló).

Mit hoz a jövő?

Jelenleg folyamatban van az új szabvány kidolgozása (FC-BB-6), mely olyan igényekre igyekszik műszaki megoldást kínálni, melyek az előzőből kimaradtak, esetleg azóta keletkeztek:

  • Magas BER értékű médiák támogatása pl. 10GBase-T
  • PT2PT kapcsolat Initiator és Target között FCF nélkül

 

 

 

 

  • VN2VN (egy broadcast domain-ben lévő Initiator-ok és Target-ek tetszőleges egymás közötti kommunikációjának biztosítása) FCF nélkül

mely gyakorlatilag a Unified Fabric harmadik fázisának felel meg:

vn2vn_thumb3_thumb[1]

Kompatibilitás

Mint már említettem, az egyik fő adaptációs félelem és egyúttal gátló tényező, a kívánt design vagy az abban szereplő eszköz(ök) nem szereplése az E2E kompatibilitási listákon. Ez ugyan nem azt jelenti, hogy a kérdéses design nem működőképes, hanem azt, hogy a storage gyártó által nem került tesztelésre, validálásra. Egy nem támogatott design alapú implementáció kockázatot hordoz magában, hiszen amennyiben működései hibák lépnének fel, nem számíthatunk gyártói segítségre.
Szerencsére, mint már említettem, a storage gyártók gőzerővel dolgoznak a kompatibilitási listák bővítésén, néhány validált szcenárió a teljesség igénye nélkül:

pl. Cisco Nexus 5000:

De további listákat is megtekinthetnek az alábbi linkeken:

Meglátások:

  • FC-vel számolni kell az elkövetkező években is. Az SSD-k elterjedése lényegesen megnövelte a tárolók IOSP kapacitását, ezért ennek megfelelően a SAN hálózat kapacitását is bővíteni szükséges. Megjelentek a 16G FC HBA-k, az új tárolók alapértelmezetten 16G FC interfészekkel rendelkeznek a Front-End oldalon, ugyanakkor a Back-End oldalon az FC térnyerést veszít a SAS, SATA technológiákkal szemben.
  • FCoE – az alaplapi CNA kártyák elterjedésével, access oldalon várhatóan erősödni fog az adaptáció, a multihop FCoE valós lehetőség de térnyerése még bizonytalan.
  • Jogos kérdés lehet, hogy a 16G FC megjelenésével, hogyan lesz képes az FCoE felvenni a harcot a kapacitástöbblettel, de már megjelent a 40G FCoE támogatás a közelmúltban bejelentett Nexus 6000 eszközök esetén és itt még nincs vége … (100G FCoE)
  • PT2PT, VN2VN (FCF nélkül) érdekesség kategória, figyeljünk a fejleményekre.
  • Véleményem szerint összességében az várható, hogy az a hagyományos adatközponti modell és a Unified Fabric legalább középtávon párhuzamosan fejlődnek tovább valamilyen dinamikával, élni és élni hagyni alapon, aztán majd meglátjuk, hogy mit hoz a jövő …

Források:

http://www.ieee802.org/1/pages/802.1bb.html
http://www.ieee802.org/1/pages/802.1az.html
http://www.fcoe.com
http://www.t11.org/ftp/t11/pub/fc/bb-5/09-056v5.pdf
http://www.t11.org/t11/stat.nsf/89dcdcf87b06cf7e85256ebd000a3a96/e2e35d69f0675ebd852576070081712f?OpenDocument
http://brasstacksblog.typepad.com/brass-tacks/2011/03/index.html
http://brasstacksblog.typepad.com/brass-tacks/2011/10/index.html

És ha valaki esetleg számolgatni szeretne, itt talál egy  TCO kalkulátort.

Cimkék: , , ,

Hozzászólás írása

Hiba az űrlap kitöltése során!

* A csillaggal jelölt mezők kitöltése kötelező

*
*
*
*