Előző cikkeimben „szigetszerűen” telepítettem ESX 3.5 vagy ESXi 3.5 kiszolgálókat. Felügyeletükhöz a szerverre kapcsolódva letölthető VI klienst használtuk. Természetesen ez csak a kezdet, az ESX VI környezet előnyeit több fizikai gépből álló fürt (clusa ter) estén tudjuk kamatoztatni. Ehhez azonban egy központi felügyeleti szerver kell telepítenünk, melynek neve Virtual Center. Ez egy Windows 2003 szerverre épülő szoftver, mely egy MS SQL (vagy Oracle) adatbázis háttérrel támogatva az összes ESX/ESXi kiszolgáló együttes felügyeletét ellátja. Ilyenkor a VI kliens nem a fizikai kiszolgálóhoz, hanem a Virtual Center szerverhez kapcsolódik. Ebben a formában már definiálhatunk szerverek közötti kapcsolatokat, úgymint „Adatközpontok/DataCenter” vagy „Fürtök/Cluster”. Az így definiált gépcsoportokon már elérhetőek olyan szolgáltatások is, melyek a folyamatos üzemet támogatják (COS). Ide tartozik a virtuális gépek fizikai kiszolgálók közt történő tervezett mozgatása (VMotion) illetve az erre épülő szolgáltatások úgymint DRS vagy DPM. A magas rendelkezésre állást a 3.5-ös ESX szerverek esetén a HA agent biztosítja, mely nem tervezett esetekben valamely kiszolgáló kiesése esetén a leállt virtuális gépeket a fürtben elérhető szabad kapacitású kiszolgálókon újraindítja. A kiesés ilyenkor az észrevételi idő (15 mp, de állítható) plusz a virtuális gépek újraindítási idejével arányos. Akinek ez nem volna elég, és katasztrófatűrő telephelyek építésén gondolkoznak, ők a VMware SRM-et nézegessék. Egy másik irány a hibatűrő rendszerek világa, vagyis az FT (Fault Tolerance). Jelenleg az ESX 3.5-ben ilyen jellegű támogatás még nem elérhető. Termszetesen továbbra is lehet szoftveres clustering-et alkalmazni a különböző fizikai gépek azonos virtuális hálózatára kapcsolódó virtuális gépei között (DNS, MS Clustering, Linux Clusterek, stb. Lehet próbálkozni Oracle RAC-cal is, működik, de a támogatást ekkor inkább valamely szolgáltató partnertől kérjük, mint közvetlen a RAC gyártójától).

Tesztkörnyezet a bemutatóhoz

Az egyszerűség kedvéért olyan tesztkörnyezetet választottam, amit bárki kipróbálhat otthon is. Nem kell hozzá más, mint 1-2 olyan desktop vagy notebook, melynek a CPU-ja Intel-VT képes.

Az alábbi virtuális gépeket hoztam létre VMware Workstation 6.5.1 alatt:

· SAN01, egy Openfiler gép (iSCSI megosztott hálózati tárolónak fogom használni)

· ESX01 az egyik ESX hoszt

· ESX02 a másik ESX kiszolgáló

· Windows 2003 R2 Standard x32, ez a VirtualCenter kiszolágóia

· Valamint egy gazdagép, ahol a VI kliens fut, illetve a virtuális gépekre lehet kapcsolódni

Természetesen, a valóságban fizikai gépekre telepítünk, lehetőség szerint helytakarékos BLADE szerű gépekre. Az iSCSI helyett inkább FC hálózatokat használunk. A Virtual Center lehet itt is virtuális gép. 5 fizikai szerver felett célszerű külön MS SQL szervert is üzembe helyezni a Virtual Center-be beépített MSDE használata helyett.

Ennek a leírásnak nem célja a teljes hálózat bemutatása, melyet a teszt környezetez használtam. Célom elsősorban az volt, hogy bemutassam, milyen szolgáltatások érhetőek el az ESX szerverekből épített VI3 környezet alatt.

Openfiler 2.3 (NAS/SAN) mint a legegyszerűbb közös iSCSI alapú hálózati tároló

Miután otthon nem igazán szokott lenni FC hálózat és közös pl. EMC lemezrendszer, valamint a HBA kártyákat nem igazán desktop gépekbe szokták tenni így a legkézenfekvőbbnek a mostani teszthez egy bárki számára ingyenesen elérhető Openfiler iSCSI tároló bizonyult.

http://www.openfiler.com/about [1]

A virtuális gépet még csak telepíteni sem kellett, mert az Openfiler honlapjáról többféle VMware image is letölthető volt. A virtuális gépet csak el kellett indítani. Célszerűen hozzáadtam még pár virtuális merevlemezt indítás előtt.

Az Openfiler divatos webes felületen konfigurálható ingyenes NAS/SAN megoldás. Mindenféle protokolon keresztül kínálja a gépbe helyezett fizikai lemezeket. Nekünk az ESX szempontjából az NFS vagy iSCSI tudása jelent segítséget a (ESX kiszolgálók számára) közös (hozzáférésű) tárolók létrehozásában. Mivel a VMFS fájlrendszer egy fürtözött fájlrendszer, így ha egyszerre több kiszolgáló fér hozzá ugyanahhoz a kötethez, a kiszolgáló csak a fájl szinten helyez el lock-okat és nem a kötet szintjén. Így egyszerre több kiszolgáló is ugyanazt a „fizikainak látszó” merevlemezt láthatja.

Az Openfiler ezzel a képernyővel fogad telepítés után.

A hozzáadott lemezen először fizikai partíciót kell létrehozni.

Ezt követi a kötet csoport, azaz a Volume Group létrezása.

A volume group létrehozás után (illeve ezt már korábban kellett volna) kapcsoljuk be az iSCSI szervert, mert csak akkor tudunk iSCSI-ra formázott lemezeket kiajánlani.

Ne felejtsük el az iSCSI target-et beállítani, ezen az IQN-en lehet majd megkeresni a lemezeket az ESX szerverek alól.

Az előbb létrehozott kötet csoport után most már hozzunk létre egy kötetet.

Figyeljünk, hogy a típusa iSCSI legyen!

Végezetül használjuk a LUN mapping részt, ahol a LUN és VOLUME összerendelés történik. Legyen a kötet írható olvasható. A CHAP-ot nem használtam, inkább külön izolált storage hálózatot hoztam létre. Ez fizikai környezetben lehet külön kábelezve is. Az ESX szerver csak 1 CHAP felhasználónév/jelszó párt tud megjegyezni, de támogatja a CHAP azonosítást.

A VirtualCenter háttere: DNS, Microsoft AD (Active Directory)

Mielőtt nekifognánk a Virtual Center telepítéséhez, pár dolgot meg kell vizsgáljunk. Normál vállalati környezetben szokott lenne DNS illetve AD szolgáltatás. Nekem most nem volt itthon, így gyorsan összedobtam ezeket a VirtualCenter virtuális gépen.

A DNS kritikusan fontos az ESX VI környezetben. Ha valami nem megy (HA agent, vagy VI konzol elérés) minden esetben a DNS-re kezdjünk gyanakodni! A hibák 95%-ában a hibás DNS konfiguráció a felelős!

A következő képsort nem szeretném túlmagyarázni, mert nem része a cikkemnek, csak nálam kellett a demó környezet összeállításához.

Minden rendben, működik a DNS feloldás.

Az AD nem kötelező, de használata erősen ajánlott Windows Domain környezetben. Ha a VI3 környezetre később View3-at is tervezünk, akkor pedig kifejezetten hasznos a jogosultsági rendszerhez. Ha nincs AD, akkor a Virtual Center alatti Windows 2003 szerver helyi felhasználóiból gazdálkodhatunk.

Virtual Center telepítése

A következő néhány kép a Virtual Center telepítését tekinti át. Ahogy a cikk elején is említettem, erre a célra külön létrehoztam egy virtuális gépet. Valódi éles környezetben is szokták virtuális gépként létrehozni a VirtualCenter-t. A telepítés esetemben a DNS és AD mellé kerül. A valóságban az AD és DNS összevonható, de a VirtualCenter-t mindenképpen egy külön erre a célra dedikált Windows szerverre tegyük!

Válasszuk a VirtualCenter szerver lehetőséget!

Ahogy említettem, ha 5-nél több ESX-et akarunk felügyelni, akkor ne a helyi MS SQL 2005 expressz változatot használjuk, hanem egy meglévő teljes MS SQL 2005+ szerveren hozzunk létre a VIM számára egy külön adatbázist!

Ha van liszenszünk, már a telepítés elején megetethetjük vele! Az EVAL idő lejárta előtt a liszenszt a VirtualCenter szerveren egy kis eszköz segítségével lehet kicserélni (liszensz tool) a szerviz újraindításával.

Útmutató az ajándék (kölcsön) lóhoz. Sokan nem tudják pontosan mi lesz, amikor lejár a 60 nap? Az adatok természetesen nem vesznek el, de virtuális gépeket nem tudunk majd elindítani az ESX hosztokon. Az ESXi-n amúgy igen, de csak szigetszerűen újra VirtualCenter nélkül.

Becsapós, de ez nem új felhasználót hoz létre, hanem meglévő admin felhasználóra kérdez rá.

Ha még nem lenne, a telepítés során kapunk ajándékba egy .NET FrameWork 2.0-át.

Illetve az említett helyi MS SQL adatbázist.

Kész is van. Most akár a VirtualCenter szerveren, akár távolról is rá tudunk kapcsolódni a Management szerverre.

Virtual Center Server, első lépések (adatközpont létrehozása, fizikai gépek regisztrációja)

A VirtualCenter szerver egyszerű telepítését követően csatlakozzunk a szerverhez pontosan úgy, ahogy korábban az ESX szerverekhez kapcsolódtunk, csak más az IP cím, és itt jellemzően nem root hanem  administrator lesz a felhasználónév (Windows környezet, AD backend).

Sajnos a Virtual Center jelenlegi változata nem tud még Linux-on futni és nem ismeri az LDAP-ot sem, de szerintem csak idő kérdése, hogy teljesen „Microsoft mentes” VMware környezet lesz majd létrehozható. Ezzel is csökkentve a felesleges liszensz költségeket.

Belépés hasonlóan, mint az egyedi szerverek esetén.

No, hát megjöttünk. Az első feladat a hierarchia legmagasabb szintjének létrehozása, az ADATKÖZPONT (DC) regisztrációja. Kevesen tudják, de az adatközpont szab határt például a VMotion-nak, tehát Szegedről-Debrecenbe nem lehet költöztetni leállás nélkül a virtuális gépeket, legalábbis még nem (kivéve, ha transzparens bérelt FC hálózat van a telephelyek közt).

Első feladat a fizikai gépek Virtual Center alá történő regisztrációja.

Mi történik ilyenkor? A korábbi hostd (hoszt démon) leáll, és helyette a Virtual Center démon indul el, és jegyzi be, hogy melyik Virtual Center alá lett bekötve az ESX host.

Innentől kezdve lehet, de nem javasolt a fizikai gépek VirtualCenter megkerülésével történő felügyelete. Figyelmeztet is a rendszer, ha erre készülne valaki (VI klienssel közvetlenül kapcsolódna az ESX kiszolgálóhoz).

Adatközpont kiválasztása.

Egy fizikai szerver jellemzően egy Virtual Center alá tartozik. Ha több Virtual Center-ünk lenne, és a host gépet egy már egy korábbi VC-nek odaadtuk, akkor figyelmeztet, de a host átregisztrálható másik VirtualCenter alá (ilyenkor számolni kell a következményekkel, hiszen különálló hostra butul vissza az a gép olyankor) szóval ez nem javasolt művelet. Célszerűen egy adatközpontban egy Virtual Center fut, és a telepítés előtt tervezéssel indul a feladat (átgondoljuk az igényeket, LAN, FC, stb.)

Ez és a következő képek a hálózat beállításáról szólnak. Erről egy külön cikket írhatnék, itt csak igyekszem összefoglalni a fontosabb szabályokat:

· A HA használatához két független szerviz konzolra lesz szükség

· A VMkernel-nek külön IP címet kell adni, a VMkernel felel a VMotion illetve a IP alapú tárolók kezeléséért. Itt az iSCSI esetén ez fontos, hogy létezzen.

· A Virtual Machine típusú hálózatokat lehet kiválasztani a virtuális gépek esetén.

· Minden egyes host esetén ugyanúgy kell kinéznie a hálózati beállításoknak, ha azokból a gépekből fürtöt akarunk készíteni! Ez nagyon fontos. A felületen kattintgatásnál ügyesebb ezt ESX konfig parancssor segítségével végezni (esxcfg-vswitch)! Erről már nem írok, mert lehet a VI4-ben ez a probléma megoldódik J Amúgy számos ilyen videó található az interneten.

Sokan meglepődnek, de az ingyenes ESXi telepítése során az egyetlen észrevehető különbség a VC alól, hogy a Service Console eltűnik (pontosabban összeolvad a VMkernel-el).

IP címet adok a VMkernel-nek!

A VMkernel esetén nem szükséges Gateway címet megadni, mert a VMkernel csak az ESX gépek közti belső kommunikációért felel. Ezen keresztül meg pl. a VMotion is. Ha IP storage célokra is használjuk (ahogy én is tettem), célszerű a tárolót vele azonos subnet-en elhelyezni, hogy lássák egymást átjáró hiányában is.

Hozzáadom a másodlagos szerviz konzolt is.

A másodlagos szerviz konzol esetén később is meg lehet adni az Gateway IP címét.

Így néz ki a teszt hálózatom. Készen van!

Nagyon fontos, hogy az ESX kiszolgálók órája együtt járjon! Ehhez mindenképpen aktiváljuk és állítsuk be az NTP klienst!

Példámban itt a kfki.hu szerverét használom.

Új fürt létrehozás (VMware HA és DRS beállítása)

A következő lépésekben egy új fürtöt fogok létrehozni.

Az adatközpont definiálása után (nálam itt VMUG) a következő szint a Cluster-ek szintje. Gyakori kérdés, hogy milyen gépeket lehet egy fürtbe szervezni? Röviden a válaszom, az egy processzor családba tartozó gépeket (tehát nem lehet keverni az INTEL-VT és AMD-V technológiákat, azaz nem lehet egy fürtön belül INTEL és AMD processzorral szerelt gép). További korlátozás, hogy a CPU-k utasításkészletének egyeznie kell pl. INTEL esetén. Ezt azonban egy felület segítségével lehet finomítani, vagyis megoldható, hogy a régebbi szerverekhez vásárolt új szerverek processzoraiban megjelent új utasításkészleteket letiltsuk (CPU masking).

Az új fürtvarázsló a VMware HA (magas rendelkezésre állás) és DRS (terhelés-elosztó) szolgáltatások beállításában nyúlt segítséget.

Az RDS működése kapcsán három lehetőség közül választhatunk. Itt az utóbbi kettő jellemző: félig automatizált illetve teljesen automatizált. Félig automatizált beállítás esetén a rendszer csak javaslatokat tesz, hogy mely gépeket kellene átmozgatni a fizikai hosztokról, egyenletesebb terhelés érdekében. Itt a VMware a VMotion technológiát használja a háttérben. A képen található csúszka segítségével lehet „adjust-olni” az ajánlások érzékenységé: agresszív módban már kisebb CPU terhelések esetén is javaslatot tesz a rendszer. Ilyenkor félig automatizált módban a rendszergazda munkakedve alapján tesztre szabható, hogy naponta hány ajánlást van kedve a rendszer üzemeltetőjének feldolgozni (átolvasni). Lusta rendszergazdáknak a konzervatív beállítás a barátjuk. Természetesen a gyártó is tudja, hogy a terhelés elosztás pusztán a számok alapján (CPU%) nem teljesen optimális, a fejlődés az irányba megy tovább, hogy pontosan tudjuk, mi történik a dobozban. Egy komolyabb adatbázis tranzakció vagy egy vírusellenőrzés miatt nem oldódik meg a probléma, ha egy másik gépre mozgatjuk a gépet (ott is megeszi ugyanazt az erőforrást). Tehát olykor szervezési feladatok is szükségesek a rendhez: lehetőleg ne egy időben fusson a vírusirtó, mint az adatbázis tranzakció. Ez csak egy buta nem életszerű példa, de segítségével remélem érthető a DRS lehetséges továbbfejlesztési iránya. Ez a probléma amúgy bármely más hasonló szolgáltatást ajánló gyártónál jelentkezik. A megoldásban a szoftvereknek kell majd üzenniük állapotukról egy jövőbeni API segítségével, melyeket a Hypervisorra épülő management ért, és a mozgassuk / ne mozgassuk döntéseknél felhasználni. Pl. a Microsoft ez ügyben már tett ajánlásokat, de még inkább kísérleti stádiumban jár a probléma megoldás náluk is.

A HA kapcsán számos lehetőség beállítható. Akinek ez nem elég, az ADVANCED beállítások résznél lehet pöcögtetni, hogy hány másodperc után gondolja, hogy kiesett egy host, stb.

Összefoglalás, majd készen van az új fürt.

Én a fürt létrehozása után tettem bele a korábban hozzáadott gépeket, valójában célszerű előbb a fürtöt elkészíteni, majd a gépeket egyből oda regisztrálni.

A gépek (fizikai ESX-ek)  fürhöz való hozzáadáskor egy HA ügynök is települ a gépekre.

A fürt maximum 32 gépből állhat. FONTOS, hogy az első 5 gép őrzi a fürt adatbázisát, ők az úgynevezett „primary node”-ok. Pl, amikor blade-ekre telepítünk és több keretünk van, célszerű elosztani az első 5 gépet a keretek között és nem mindet az első keretből választani, mert annak tápegység hibája esetén a teljes fürt fejre állhat. Tervezési hiba miatt (hiszen ez világosan benne van a dokumentációban).

A HA agent telepítése viszonylag gyorsan végez.

Összefoglalás

Ezzel elkészítettük a virtuális gépeink számára magas rendelkezést biztosító fürtöt. Ugye nem is volt bonyolult? Tényleg nagyjából igaz a marketing blabla, hogy egyetlen pipa a magas rendelkezésre állás beállítása. Minden esetre, aki küzdött már a Linux-HA heartbeat beállítással, az ezt most biztosan nagyra értékeli. A 2003-as MS Clusteringről sokaktól hallom, hogy nem triviális annak beállítása. Igaz, a 2008 szerver esetén ez sokat javult. VMware virtualizált környezetben is támogatott effélét művelni, de szinte itt találkozunk a legtöbb korlátozással (RAW disk, stb). Elnézést, nem akartam keverni a HA és FT-t, de lássuk be hasonló dolgokról van szó, csak a HA esetén van (egy rövid) szolgáltatás kiesés, FT esetén nincs. A szoftveres clustering-gel szemben van egy hihetetlen előnye a VMware HA-nak. Operációs rendszertől függetlenül működik, mindenféle további ráfordítás (programozás vagy konfiguráció) nélkül. Gondoljuk csak át, micsoda előnye van ennek valami olyan kliens-szerver alkalmazásnál, ahol a szerver oldali szolgáltatást fejlesztő cég több milliós ajánlatot ad, hogy a szerver fürt képes tudjon lenni. Ha egyáltalán meg tudják csinálni (pl. valamilyen speciális .NET vagy Delphi egyedi fejlesztés esetén). Minden olyan esetben, ahol az SLA megengedi a szolgáltatás néhány percre való kiesését a VMware HA a barátunk. Azt gondolom ez nem csak nagy, hanem egyre inkább a kis és középvállalatok igényeiben is megfogalmazódik. Ahol heterogén környezetet használnak (Linux és Windows alapú operációs rendszerek egyaránt) a legegyszerűbb működő megoldás a VMware HA szolgáltatás beszerzése.

A HA már a Standard (közepes) változatban is elérhető szolgáltatás. Sokan nem tudják, hogy a kb. 3000 dollár befizetésekor a liszensz megosztható 2 fizikai vas közt (bizonyos vasak esetén), amennyiben a magok száma ezt lehetővé teszi. Tehát, már 1 ESX Standard liszensz segítségével is biztosítható a magas rendelkezésre állás egy két fizikai tagból álló fürt esetén!

A nyugalom ára

Vajon, kb. 740 ezer forintért (mai USD árfolyam alapján) átírja-e egy fejlesztő cég a kliens/szerver alkalmazását cluster baráttá? Vajon, hányszor lehet hétvégi túlórát fizetni ebből a pénzből a rendszergazdá(k)nak, aki(k) a meghibásodott Exhange kiszolgálót állítja(k) vissza éppen a mentésekből? Nekem a nyugodt éjszakáim ennél többet is megérnének, nem beszélve a szolgáltatás kiesése miatti kellemetlenségekről, és pénzben nem kifejezhető szégyenről, amikor az ügyfeleknek magyarázkodni kell, hogy éppen az alaplap vagy a tápegység sült el valamelyik fizikai gépben. Szerintem, a folyamatos szolgáltatás kiesés a mai napig minden szolgáltató cég rémálma, legyen az LAN vagy WAN környezet.

• Check the HOSTNAME entry in /etc/sysconfig/network to the short name
• Check if your FQDN is greater than 30 characters, in which case HA will not configure properly. This is a known bug in VC20 (see KB article 2259).
• Check IP, routing, and DNS for each host.
• Make sure that storage and network are available across the cluster – Ensure that the hosts are not managed directly: perform all host management through VC.
• May want to add nodes to /etc/hosts on ESX Server AND hosts file on VC Server. A better plan would be to use primary and secondary DNS servers.
• Check if Service Console has default gateway defined.
• Verify logs: /opt/LGTOaam512/* and /opt/LGTOaam512/vmsupport/*.
• Check /etc/hosts and /etc/resolv.conf.
• In ESX 3.x the memory reservation is zero, and the limit is “unlimited.” To see this, edit the settings of a virtual machine, click on the Resources tab, and select Memory on the left. To conform to the ESX 3.x defaults, change the settings to a reservation of 0, and check the Unlimited box under limit. After doing this for all virtual machines, edit the settings for the cluster. Disable HA, and then edit the cluser settings again to reenable HA. The current failover capacity should now match the configured capacity.

Alapvetően két megoldás létezik

1. A meglévő Service Console-hoz tartozó vSwitch-hez adunk legalább két NIC-et
2. Dedikálunk egy kölünálló NIC-et egy új vSwitch-hez, amihez aztán egy második SC hálózatot rendelünk

Látszólag egyszerű a dolog, de mindkét megoldásnak vannak erős követelményei.

Teaming

Az első megoldás tűnik a legegyszerűbbnek, azonban ez a felállás magában foglal egy lehetséges Single-Point-of-Failure, nevezetesen a mögöttes fizikai switch-et. Nyilvánvaló, ha mindkét NIC-et ugyanabba a fizikai switch-be kötjük, akkor az adott switch meghibásodása esetén az egész HA redundacia bedől. Emiatt mindenképpen külön-külön switch-be kell kábeleznünk a két Service Console-t. Azonban! Ez a kettőzés megköveteli, hogy a két fizikai port-on FastPort (Etherchannel) legyen konfigurálva, amely két fizikai switch esetében csak akkor lehetséges, ha a switch-ek STACK-elve vannak, erre pedig nem minden switch képes!!

Még egy SC

A második lehetőségünk, hogy használunk egy meglévő vSwitch-et és ezen alakítunk ki a második Service Console-t. A VMware ajánlása, hogy erre nyugodtan használjuk a meglévő VMotion-VMKernel vswitch-et, ami valóban a legegyszerűbb megoldás. Sajna ezzel is van egy kis bibi… A VMotion hálózattal szemben követelmény, hogy ez egy teljesen izolált fizikai hálózat legyen; a HA-ról pedig tudjuk, hogy erősen kötődik a DNS-hez, így rögtön felmerül a kérdés: az a Service Console hálózat, amely a VMotion hálózatot használja hogy az ördögbe fog tudni a DNS-hez csatlakozni? Szerencsére van megoldás: /etc/hosts.

Tehát ha a VMotion hálózathoz szeretnénk kötni a redundáns SC-t ezt így tehetjük meg:

1. alakítsuk ki a VMotion vSwitch-en a második SC-t és adjunk neki IP a vmotion subnet-ből
2. szerkesszük meg az /etc/hosts állomány és kézzel vegyük fel a HA cluster minden tagjának a VMotion subnet beli IP-címét
3. Bizonyosojunk meg arról, hogy az elsődleges SC-nél konfiguráltunk DNS-t és ellenőrizzük, hogy létezik-e DNS host rekord minden node-hoz (itt terménszetesen a management LAN beli IP címet kell használni)
4. szerkesszük meg az /etc/nsswitch.conf állományt, hogy ez legyen benne.
   hosts: files dns

Ennek hatására a HA cluster mindkét SC irányba képes lesz név szerint elérni a node-okat. Az nsswitch beállítása miatt előszőr a hosts file-ból fog pingelni (ekkor használja a VMotion-re kötött SC-t), és ha ez nem megy, akkor fordul a DNS-hez (mikor is a mgmt lan-hoz kötött SC-t használ).