Cisco UCS: manual failover

Jos jostain syystä haluaa vaihtaa kumpi interconnect moduleista on primary, niin tässä ohje miten se tehdään manuaalisesti. Tämä voi tulla eteen esim. kun päivittää firmikset näihin.

Ota yhteys sen hetkiseen primary -kytkimeen (CLI). Seuraavalla komennolla näkee kumpi on primary.


ucs-B# show cluster state 
Cluster Id: 0xd4324e30a60c11df-0xa87300059b73f684


A: UP, SUBORDINATE
B: UP, PRIMARY


HA READY

Tämän jälkeen vaihdetaan kytkin A primaryksi:

ucs1-B# connect local-mgmt 

Cisco UCS 6100 Series Fabric Interconnect

TAC support: http://www.cisco.com/tac

Copyright (c) 2009, Cisco Systems, Inc. All rights reserved.

The copyrights to certain works contained herein are owned by

other third parties and are used and distributed under license.

Some parts of this software may be covered under the GNU Public

License or the GNU Lesser General Public License. A copy of 

each such license is available at

http://www.gnu.org/licenses/gpl.html and

http://www.gnu.org/licenses/lgpl.html

ucs-B(local-mgmt)# cluster lead a 

Cluster Id: 0xd4324e30a60c11df-0xa87300059b73f684

Eikä muuta. Tämän jälkeen GUI pitää käynnistää uusiksi. 

'show cluster state' -näyttää jonkin aikaa tältä:

ucs-B(local-mgmt)# show cluster  state 

Cluster Id: 0xd4324e30a60c11df-0xa87300059b73f684

B: UP, SUBORDINATE, (Management services: SWITCHOVER IN PROGRESS)

A: UP, PRIMARY

HA NOT READY

Management services: switchover in progress on local Fabric Interconnect

Ehkä tuossa joku minuutti menee kun failover on tehty.

UCS: sekalaista

Server / Uplink ports


Initial asennuksen jälkeen pitää määritellä mitkä porteista on Uplink portteja (menee kytkimelle) ja Server portit (menee UCS-kehikkoon). Tämän jälkeen UCSM löytää Chassikset itsestään. Ainoa mikä on kummaa, ettei Chassiselle voi antaa oikein mitään nimeä tai mitään muutakaan tagia millä sen tunnistais.

Uplink porteista tulee samantien trunk-portteja.

Näyttää tältä jos käy CLI:stä kattomassa.


ucs1-A# connect nxos

-ucs1-A(nxos)# show run interface ethernet 1/9

version 4.1(3)N2(1.3i)

interface Ethernet1/9

  switchport mode trunk

  switchport trunk allowed vlan 1,52

  pinning border

  no shutdown

FC-ports


FC-porteille ei tarvitse oikeastaan muuta tehdä, kuin valita VSAN mihin ne halutaan kytkeä.
Itse pistin kaikki loput portit disabled tilaan varmuudeksi.

UCS FC-puoli on NPV moodissa ja kytkimen tulee olla sitten NPIV.
NPV/NPIV:stä oli hyvä juttu tässä

UCS firmisten päivitys


Päivitin tuossa aluksi koko UCS-järkän firmikset. Kaikki meni suht. ok, mutta tietty testinä vähän vielä huono, kun ei ole tuotantoa. Jossain vaiheessa sitten juttua miten se meni tuotannossa.

Tätä dokkaria kun seuraa, niin sujuu ihan hyvin:

http://www.cisco.com/en/US/products/ps10281/prod_installation_guides_list.html

Tuolta sit valitsee oikeen version.

Management IP pool / KVM-yhteys


Palvelinten etäyhteys toimii KVM-java-kikkulalla. Jotta KVM-yhteys toimii, pitää ensin
luoda Management IP pool (Admin -> Management IP pool).

Yritin ensin leikkiä fiksua ja tehdä sille oman VLAN:n, mutta eihän se niin onnistunut vaan tän poolin IP-osoitteiden tulee käytännössä olla samassa aliverkossa ku itse hallinta (eli liikenteen pitää tulla mgmt-porteista sisään). Tein kuitenkin oman poolin ja lisäsin vain reitittimeen secondary IP:n.

UUID pools


Tähän en löytänyt oikein mitään vihjeitä miten näitä olisi hyvä luoda, mutta loin kuitenkin uuden poolin, joka alkoi 0001-xxxxxxxxx (sopiva määrä merkkejä). 0001 on sitten clusterin ID, jos näitä joskus tulee lisää. Samaa 01 numerointia voi sitten käyttää WWN/MAC pooleissa. Ehkä tää on hyvä, ehkä ei :)

MAC / WWN Pools


Näihin selvästi kannattaa harjoittaa jonkinlaista miettimistä. Tästä aiheesta oli hyvä blogikirjoitus, jonka mukaan itse aattelin ks. poolit rakentaa.

http://vblog.wwtlab.com/2010/07/22/ucs-wwn-and-mac-pools/

VLANs


Tässä nyt ei kauheesti mitään sen erikoisempaa oo, tekee vaan VLANeja sitä mukaa ku tarvii. Jos VLANia luodessa antaa siihen vaikka 10-20, niin se luo sitten noi kaikki VLAN:t kerralla, ihan näppärää.

Service profile template


Service profiilit on varmaan tärkein osa UCS:ää. Ja yleensäkin kaikki poolit ja templatet yms, joiden kautta mikään ei ole riippuvaista oikein mistään. Kun uuden palvelimen laittaa kehikkoon, niin se saa kaiken tiedon profiileista mitä olet itse määritellyt. Tuntuu että noita on ihan älytön määrä mitä kaikkea voi määritellä.

Service profile kuitenkin annetaan jollekin blade slottille, joten tämmöinen täytyy olla, että blade yleensäkään toimii. Kaiken voi varmaan tehdä default asetuksillakin tosin, jos ne riittää.

SP:n luomiseen tarvitaan seuraavat

 - UUID pool
 - Local Disk configuration Policy (katsoo onko default tyydyttävä, mutta tässä voi määritellä esim. haluaako että sisäiset kovatlevyt on RAID-1 (peili)
 - WWNN -pool / HBA jutut (jos tarvitsee storage juttuja)
 - VLANin ja sen myötä myös MAC-poolin
 - Boot policyn (mistä boottaillaan ekana, tokana jne..) - tässä default on suht. ok
 - IPMI -profiilin (vähän tietoa IPMI:stä)
 - SoL -profiili (Serial over LAN)

Näillä saa jo Service Profiilin luotua. Tän kun tekee kerran esim. ESX-hostille, niin näistä templateista voi sitten kloonata näitä niin paljon kuin haluaa.

Service profiileissa on vielä valittava joko initial template tai updating template. En lupaa, että sanomani menee vielä oikein, mutta initial template ei päivity itse service profliileihin. Eli kun teet templatesta kloonin, jonka sitten annat jollekin bladelle, niin profiili on itsenäinen. Jos teet updating templaten, niin templatea muuttamalla muutat kaikkien koneiden asetuksia, jotka ks. templatea käytät.

Esim, jos lisää templateen uuden verkkokortin, niin tallennusvaiheessa UCSM ilmoittaa että "tämä ja tämä slot pitää boottaa, että muutos tulee voimaan". Siinä kannattaa sitten miettiä kaksi kertaa jos on tuotannossa olevia koneita :)

No, kuitenkin, noilla sain itse asennettua ekan ESXi -koneen ja verkkokin toimi, joten hyvin meni :)
Okei, storagea ei vielä ole, mutta siitä tulee juttua tässä lähiaikoina.

UCS emulator

Tämmöinen tuli vastaan. Ihan toimiva emulaattori, jos haluu harjoitella jotain juttuja.

http://developer.cisco.com/web/unifiedcomputing/ucsemulatordownload

Naputtelee vaan tiedot, niin tuon saa imutella.

Vaatii VMWare playerin toimiakseen tai muun vastaavan.

UCS: initial config

Tämmöiseltä näyttää initial config UCS:ssä, eli kun ekan kerran ottaa konsolin 6120 tai 6140 -kytkimeen.
Kysymykset on aika yksinkertaisia ja asennus on suht. helppo.

HUOM, system nameen kannattaa antaa tämän clusterin nimi, eikä kytkimen nimi, kuten itse tein.. tosin alla on ohje miten se muutetaan jälkikäteen.


  Enter the configuration method. (console/gui) ? console
  
  Enter the setup mode; setup newly or restore from backup. (setup/restore) ? setup


  You have chosen to setup a new Fabric interconnect. Continue? (y/n): y


  Enter the password for "admin": 
  Confirm the password for "admin": 
    
  Do you want to create a new cluster on this Fabric interconnect (select 'no' for standalone setup or 'yes' if you want this Fabric interconnect to be added to an existing clus


  Enter the switch fabric (A/B) []: A


  Enter the system name:  ucs1


  Physical Switch Mgmt0 IPv4 address : 10.0.0.4


  Physical Switch Mgmt0 IPv4 netmask : 255.255.255.0


  IPv4 address of the default gateway : 10.0.0.1


  Cluster IPv4 address : 10.0.0.3


  Configure the DNS Server IPv4 address? (yes/no) [n]: y


    DNS IPv4 address : 10.0.0.100


  Configure the default domain name? (yes/no) [n]: y


    Default domain name : test.net


  Following configurations will be applied:

    Switch Fabric=A

    System Name=ucs1

    Physical Switch Mgmt0 IP Address=10.0.0.4

    Physical Switch Mgmt0 IP Netmask=255.255.255.0

    Default Gateway=10.0.0.1

    DNS Server=10.0.0.100

    Domain Name=test.net

    Cluster Enabled=yes

    Cluster IP Address=10.0.0.3

  Apply and save the configuration (select 'no' if you want to re-enter)? (yes/no): yes

  Applying configuration. Please wait.

  Configuration file - Ok

Sen jälkeen toinen kytkin konsolilta:

  Enter the configuration method. (console/gui) ? console

  Installer has detected the presence of a peer Fabric interconnect. This Fabric interconnect will be added to the cluster. Continue (y/n) ? y

  Enter the admin password of the peer Fabric interconnect: 

    Connecting to peer Fabric interconnect... done

    Retrieving config from peer Fabric interconnect... done

    Peer Fabric interconnect Mgmt0 IP Address: 10.0.0.4

    Peer Fabric interconnect Mgmt0 IP Netmask: 255.255.255.0

    Cluster IP address          : 10.0.0.3

  Physical Switch Mgmt0 IPv4 address : 10.0.0.5

  Apply and save the configuration (select 'no' if you want to re-enter)? (yes/no): yes

  Applying configuration. Please wait.

Aikas helppoa. Tuon jälkeen pääsee kiinni HTTP:llä hallintaan. Vaatii kyllä javan, uh.

Semmoinen minkä huomasin, että jos ryssii ton SITE NAMEN (kuten itse tein), niin sen saa näin korjattua:

Otetaan yhteys ssh:lla kytkimeen.

vanha-ucs1-A# scope system

vanha-ucs1-A /system # set name uusi-ucs1

vanha-ucs1-A* # commit-buffer

Ja uusi clusterin nimi (system name) on käytössä. 

UCS: kaapelointi

Noni, vihdoin pääsee asentamaan Ciscon UCS:n alusta loppuun, joten tulen pistämään tänne kaikenlaista matkan varrelta ja linkkejä juttuihin, katotaan mitä tulee.

Noista itse komponenteista olikin jo aikaisemmin juttua.

Itte UCS hujahti räkkiin aika nätisti, kun mukana oli hyvät kiskot. Sähköä laitettiin tosiaan se 4kpl (n+1), C19/C20 liittimillä (Tän näköinen liitin). Kannattaa muuten huomata, kun UCS:ää tilaa, että liittimet mitkä siinä tulee mukana on C13/C14 (Tämmöinen). Tuossa on käsittääkseni se ongelma, että C13/C14 on 10A ja C19/C20 on sitten 16A ja jos laskee, että UCS:n yksi poweri vie 2500W, niin siitä laskettuna tulee (2500W/230V = n. 10.8), joten 10A ei riittäisi. No joku korjatkoon jos oon kauheesti väärässä :)

Kaapelointi


Alkuun pitäisi laskea vähän millaista kapasiteettia kaipaa ja minkälainen verkko on, että voi tehdä oikeanlaisen kaapeloinnin.

UCS FEX -> Fabric Interconnects 


FEX:stä (Fiber Extension, toinen nimi IOM, eli kortti joka on UCS kehikon takana) voidaan siis vetää 1,2 tai 4 kaapelia Interconnectiin. FEX-moduuleita on 2 kpl (ok, voi olla yksi, mutta en tiedä onko se fiksua), joten kaapeleita tulee siis käytännössä 2,4 tai 8. Tämä riippuu aivan siitä miten paljon kaistaa tuohon haluaa käyttöön. Eli kun yksi kaapeli on aina sen 10Gbp/s, niin 20Gpb/s olisi ns. minimi. Ehkä kuitenkin jos ajaa levyliikenteen noista läpi myös (NFS/FCoE/iSCSI), niin melkein voisi suosia, että lähtee neljällä liikelle. Itse ajattelin näin tehdä myös tässä esimerkissä.

Mutta tietysti jokainen asennus on erilainen ja näiden FEX:stä lähtevien kaapeleiden määrä vaikuttaa suoraan siihen, miten monta UCS-kehikkoa yhteen clusteriin voi laittaa.

Blogi-kirjoitus UCS:n skaalautuvuudesta, jossa myös taukukko noista kaapeli / palvelin määristä:
http://rodos.haywood.org/2009/06/scaling-cisco-unified-computing-system.html

Kuvana se näyttää tältä:

Vasemmanpuoleinen on FEX A ja oikea sitten FEX B. On tärkeää huomata, että FEX A:sta kaapelit menevät vain toiseen fabriciin, eikä koskaan sekoiteta niitä keskenään. Eli FEX A:sta kaapelit vain yhteen 6120XP (tai 6140) -kytkimeen.

Kaapeleista vielä sen verran, että jos käytössä on 1 kaapeli, niin kaikkien palvelimien liikenne kulkee sitä kautta (doh). Kahdella kaapelilla liikenne muuttuu niin, että parilliset serverit menevät porttia 1 pitkin ja parittomat porttia 2 pitkin. Neljällä sitten taas niin, että palvelimet 1,5 -> port1, 2,6 -> port2, 3,7 -> port3, 4,8 -> port4. UCS tekee tämän itsestään, eikä siihen voi vaikuttaa, mutta ihan kurisioteettina.

Fabric interconnect (6120/6140XP)


Itse kytkimet, missä oikeastaan kaikki älykin on, näyttääpi tältä:

(Ärsyttävää oli muuten, että noi powerit on etupuolella..)

Kaavakuvana:

Ihan vasemmalla on L1/L2 portit, jotka vedetään toisen kytkimen vastaaviin portteihin. Tän kautta kytkimet vaihtavat tiedot ja pitävät itsensä keskenään synkassa. Portit ovat 1G eth-portteja, joten tavallinen CAT5 tms kaapeli kelpaa. L1/L2:n vieressä on 2 kpl Management portteja, joten niihin sitten hallinta yhteys. Hallinta tarvitsee (jos tekee clusterin) 3 IP-osoitetta. Muuten IP-osoitteita ei sen enempää tässä vaiheessa menekään (jotta palvelimen hallinta (KVM yms) toimii, niin se muistaakseni vaatii sitten erikseen IP-osoitteet, mutta niistä myöhemmin).

Kytkimet sitten arpovat keskenään kummasta tulee primary ja kummasta subordinary.

Tässä on hyvä kirjoitus, miten UCS toimii, jos kytkimet menettävät yhteyden toisiinsa.
http://blog.aarondelp.com/2010/02/how-cisco-ucs-deals-with-split-brains.html

Porteista vielä, että 8 ensimmäiseen porttiin voi myös laittaa 1G SFP+ -optiikan. Muuten kaikki portit ovat 10G SFP+. Joten ei pitäisi olla merkitystä minkä kaapelin kytkee mihinkin..

Kuvan slot2, eli expansion slottiin sai kiinni joko lisää ETH-portteja tai sitten fiber channellin. FC:ssä kaapelit vedetään siitä FC-kytkimiin, mutta tästä lisää myöhemmin.

Itse UCS:n verkottamisesta, niin peruslähtökohta on suunnilleen tämmöinen (Ciscon sivuilta):

Tähän rakennetaan muuten aika identtinen setuppi, paitsi uplinkkejä tulee olemaan vain yksi per Interconnect (siis yksi kaapeli per interconnect -> kytkin, eli 2 kpl per interconnect, kun kytkimiä on kaksi vikasietoisuuden kannalta.. no kuten kuvassakin on:)).
Tämä nyt lähinnä siksi, että 10G riittää hyvin, homma pysyy yksinkertaisena, port-channelin kanssa on ollut ihmisvirheitä ennenkin, joten sillä mennään. Meillä ei ole nexuksia, joten vPC:tä ei voi käyttää.

Näiden konffaamisesta sitten joskus juttua, kun pääsen itsekin hommassa eteenpäin.

Sillä välin tää on ihan loistava pätkä, missä on hyvin selitetty kaikki tuon verkoista:
http://bradhedlund.com/2010/06/22/cisco-ucs-networking-best-practices/

Ens kerralla UCSM:n initial configuraatio jne tulossa.

VMware: Setup found that multiple schemas exist in the database, please remove the extra schema(s) before continue.

Päivitysyritys Vcenter 4 -> 4.1:stä päätyi otsikossa olevaan virheeseen.

Muistaakseni kun 2.5 -> 4 teki tuon, niin se suostui jatkamaan päivitystä, mutta herjasi siitä. Nyt ks. ongelma piti korjata.

(En ole mikään tietokanta-asiantuntija, joten en ota näistä mitään vastuuta :))

Ongelman näkee, jos antaa tietokannassa (tässä oli SQL2005 kyseessä) seuraavan select -lauseen:

SELECT distinct sys.schemas.name AS schema_name FROM sys.objects INNER JOIN sys.schemas ON sys.objects.schema_id = sys.schemas.schema_id and sys.schemas.name 'sys'

Jos ylläoleva SELECT palauttaa 2 schemaa, niin kaikkien procedurien, viewien ja table omistajuus pitää vaihtaa dbo -omistajalle.


Seuraavilla komennoilla itselläni ainakin homma korjaantui. Muista ensin sammuttaa Vcenter ja ottaa kannasta backup.


Muuta usrvcenter kohtaan oman tietokantasi nimi.



SELECT 'ALTER SCHEMA dbo TRANSFER ' + s.Name + '.' + p.Name FROM sys.Procedures p INNER JOIN sys.Schemas s on p.schema_id = s.schema_id WHERE s.Name = 'usrvcenter'

SELECT 'ALTER SCHEMA dbo TRANSFER ' + s.Name + '.' + p.Name FROM sys.Tables p INNER JOIN sys.Schemas s on p.schema_id = s.schema_id WHERE s.Name = 'usrvcenter'

SELECT 'ALTER SCHEMA dbo TRANSFER ' + s.Name + '.' + p.Name FROM sys.Views p INNER JOIN sys.Schemas s on p.schema_id = s.schema_id WHERE s.Name = 'usrvcenter'

Jonka jälkeen se tulostelee paljon rivejä, tyyliin:

ALTER SCHEMA dbo TRANSFER usrvcenter.VPXV_VMGROUPS
ALTER SCHEMA dbo TRANSFER usrvcenter.VPXV_STAT_COUNTERS 
...


Tämän jälkeen suorita nuo kaikki ALTER SCHEMA -rivit, mitä nuo kolme SELECT-lauseketta tulosti.

Tämän jälkeen päivitys suostui menemään eteenpäin.

Toinen juttu mikä kannattaa muistaa, että ODBC pitää 4.1:ssä olla 64-bit.

Ja pari linkkiä, joista voi olla apua multiple schema -ongelman kanssa:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1011386

http://communities.vmware.com/thread/252116