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

Zimbra: domain restore

Pikaisesti ohje käyttäjien palautukseen, jos olet myös tuhonnut domainin.

• Kannattaa aluksi kokeilla vain normaalisti GUI:sta palautusta, josko se toimisi, mutta jos ei niin seuraavaksi voi kokeilla:
• Luo domainin uusiksi GUI:sta
• komentoriviltä 'zmprov -ra -a account@domain'
• Jos ylläoleva ei toimi, voi kokeilla seuraavaa:
• komentoriviltä komento 'zmrestore -c -ca -pre restored_ -a '
• En tiedä miksi se haluaa tuon -pre -vivun, mutta ilman sitä se ei toiminut
• Tämän jälkeen voi uudelleennimetä tunnuksen: 'zmprov ra restored_account@domain account@domain'

Vivuista vielä: -c jatkaa vaikka virheitä tulisi, -ca luo tunnuksen, -a on account, -ra palauttaa myös ldap datan.

Jos on useampi mbox-palvelin, niin cachessa voi olla vielä väärää tietoa domainista kun luot sen uusiksi. Voit flushata tiedot palvelimelta komennolla 'zmprov flushcache domain'

Cisco UCS part #1 - perusjuttuja

Yritän tässä kasailla nyt kesän, syksyn aikana asennus yms. juttuja Ciscon UCS:stä. (Unified Computing System). Ensin kasataan itse UCS, tehdään sille kahdennettu verkko, liitetään Netapp storageen; sekä FC, että NFS. Tämänjälkeen laitetaan ESX pystyyn, tehdään VNLinkillä yhteyksiä ja katsotaan miten kaikki saadaan toimimaan nätisti keskenään.

Cisco toi UCS:n (aka. Project California) vähän aikaa sitten markkinoille. Sen tarkoitus olisi Ciscon sanoin yhdistää niin verkko, levy (storage), palvelin virtualisointi yhdeksi kokonaisuudeksi.

Ciscon ajattelutapa eroaa aika paljon siinä, että kehikon "aivot" tuodaan kytkimeen sensijaan, että jokaisessa kehikossa olisi omat "aivot", kuten mm. HP ja Dell tekee. Tämä tietysti auttaa siinä, että kehikko itsessään on vain rautaa ja hintaa saadaan siinä alaspäin, joskin kytkimet tietysti maksavat enemmän. Samoin Ciscon PALO-kortti (M81KR) on erittäin mielenkiintoinen ja tarjoaa varmasti jännittäviä konffaushetkiä ja vähän muuttaa tapoja tehdä asioita.

Hommahan koostuu alla olevan kuvaisesti seuraavista komponenteista (Ciscon sivuilta poimittu kuva)

Alhaalta ylöspäin. Taino, keskeltä alas ja sitten ylös.

Keskellä on kehikko (5100 malli), johon saa 8 puolileveää tai 4 täysleveää palveinta kiinni.
Taakse laitetaan 2 kpl Fabric Extenderit (UCS 2104XP), joista yhdestä FEX:istä saa 4 kpl 10G yhteyttä kiinni UCS-kytkimiin. Kehikossa on 8 tuuletinta. Sähköä se muistaakseni söi 4 x 2500W powereita, jotka pystyivät olemaan muutamalla eritavalla kytkettyinä. Itse suosisin n+1 mallia. Korkeus on 6RU.

Kehikossa itsessään ei ole mitään älyä, joten siitä ei ole kauheasti mitään sen ihmeellisempää kerrottavaa.

Bladeja taitaa tällä hetkellä olla saatavilla B200 (puolileveä) ja B250 (täysleveä).
B2x0 -sarjalaiset tukevat Intelin 55xx prosessoreja. Ilmeisesti on tullut myös B4xx sarjalaisia, joissa on sitten Intelin 56xx ja 75xx malleja, mutta niistä en tiedä sen tarkemmin.
B200:een saa maksimissaan 96GB muistia (12DIMM) ja B250 tukee 384GB (48DIMM).

B200 saa yhden mezzanine kortin ja B250:een 2. Näinollen B200 thruput on 20Gbps max ja B250 40Gbps.

Mezzanine kortteja on seuraavanlaisia:

 • Cisco UCS 82598KR-10 Gigabit Ethernet Network Adapter

• Cisco UCS M71KR-Q QLogic Converged Network Adapter

• Cisco UCS M71KR-E Emulex Converged Network Adapter

• Cisco UCS M81KR Virtual Interface Card

Tulen käymään läpi tuota M81KR korttia enemmän jatkossa, koska tuo on yksi syy, miksi Ciscon UCS on kiinnostava.

Kehikosta mennään FEX:in kautta UCS kytkimiin (6120/6140 mallit). FEX:stä kytkimiin laitetaan kaapeleita tarpeen mukaan. Muistaakseni joko 1,2 tai 4 10G yhteyttä (per FEX). Maksimi thruput on silloin 80Gpbs per kehikko.

UCS kytkimistä (Fabric Interconnect) sitten tulee ihan omia juttuja. Kytkimissä on oikeastaan kaikki mitä UCS itsessään on. Yhteen UCS järjestelmään voi kytkeä 40 UCS kehikkoa (max 320 puolileveää palvelinta). Jokatapauksessa kytkimessä on 20 tai 40 10Gpbs porttia (SFP+) ja lisämahdollisuutena voi siihen laittaa 8 porttisen 1/2/4Gbps FC (Fiber Channel) kortin, 6 porttisen 1/2/4/8Gbps FC-kortin, 6 porttinen 10Gbps eth-kortti tai 4 FC + 4 eth 10Gbps kortin.

Hyvä, sekava kirjoitus.. kyl tää tästä :)

Netapp: Metroclusterin peilauksen purkaminen

Lyhyt ohje peilauksen purkamiseen metroclusterissa. Peilaus on ainakin hyvä purkaa, jos clusterin jäsenet ovat pitkään irti toisistaan. 

Peilauksen purku ei aiheuta mitään katkoksia tuotantoon. Lähinnä se aiheuttaa vaan jännitystä, kun pelottaa jos jokin menee pieleen :)
Ensin kannattaa katsoa kumpi on paikallinen levyosio ja kumpi peilipuolisko, jotta tietää kumman haluaa ottaa irti. Alla olevasta näkee sen parhaiten oikeastaan kytkiten nimistä jos ne on nimetty "järkevästi". Tässä tapauksessa plex1 on peiliosio.

Seuraavalla komennolla näkee aggrekaatin rakenteen:

netapp-a> aggr status -r aggr0
Aggregate aggr0 (online, raid_dp, mirrored) (block checksums)
  Plex /aggr0/plex0 (online, normal, active, pool0)
    RAID group /aggr0/plex0/rg0 (normal)


      RAID Disk Device               HA  SHELF BAY CHAN Pool Type  RPM  Used (MB/blks)    Phys (MB/blks)
      --------- ------               ------------- ---- ---- ---- ----- --------------    --------------
      dparity site1-san-be-sw2:3.16 0c    1   0   FC:A   0  FCAL 10000 272000/557056000  280104/573653840
      parity   site1-san-be-sw1:3.17 0a    1   1   FC:B   0  FCAL 10000 272000/557056000  280104/573653840
      data     site1-san-be-sw2:3.18 0c    1   2   FC:A   0  FCAL 10000 272000/557056000  280104/573653840
      data     site1-san-be-sw1:3.19 0a    1   3   FC:B   0  FCAL 10000 272000/557056000  280104/573653840
jne...


  Plex /aggr0/plex1 (online, normal, active, pool1)
    RAID group /aggr0/plex1/rg0 (normal)


      RAID Disk Device               HA  SHELF BAY CHAN Pool Type  RPM  Used (MB/blks)    Phys (MB/blks)
      --------- ------               ------------- ---- ---- ---- ----- --------------    --------------
      dparity site2-san-be-sw1:5.16 0a    1   0   FC:B   1  FCAL 10000 272000/557056000  280104/573653840
      parity   site2-san-be-sw1:5.17 0a    1   1   FC:B   1  FCAL 10000 272000/557056000  280104/573653840
      data     site2-san-be-sw1:5.18 0a    1   2   FC:B   1  FCAL 10000 272000/557056000  280104/573653840
      data     site2-san-be-sw1:5.19 4b    1   3   FC:B   1  FCAL 10000 272000/557056000  280104/573653840
jne...

Sitten vaan splitataan aggrekaatti.
Täältä löytyy koko aggr komennon manuaali: http://www.wafl.co.uk/aggr-2/

Tuo split tekee siis sen, että sille ensin kerrotaan kumpi plexeistä irroitetaan pois. Eli halutaan se peilattu osio irti. Tämän jälkeen se luo uuden aggrekaatin, esimerkissä aggr99 -nimisen. Tämän jälkeen aggr0 ja aggr99 on täysin identtiset ja aggr99:n alla on samat volumet kuin aggr0:ssa. Kaikki volumet kuitenkin pistetään offline tilaan, jotta konflikteja ei tapahdu. Tämä myös näkyy tuossa esimerkissä.

netapp> aggr split /aggr0/plex1 aggr99

Mon Jun 28 12:27:35 EEST [netapp: fmmb.lock.disk.remove:info]: Disk site1-san-be-sw1:5.17 removed from local mailbox set.

Mon Jun 28 12:27:35 EEST [netapp: fmmb.lock.disk.remove:info]: Disk site1-san-be-sw1:5.16 removed from local mailbox set.
Mon Jun 28 12:27:37 EEST [netapp: fmmb.current.lock.disk:info]: Disk site2-san-be-sw1:3.17 is a local HA mailbox disk.
Mon Jun 28 12:27:37 EEST [netapp: fmmb.current.lock.disk:info]: Disk site2-san-be-sw2:3.16 is a local HA mailbox disk.
Mon Jun 28 12:27:37 EEST [netapp: wafl.vv.regen.FSID:notice]: For flexible volume 'root' (created via a split of a formerly mirrored-aggregate), regenerated FSID (0d31bba4) host 0.
Mon Jun 28 12:27:37 EEST [netapp: wafl.vv.rename.dup:notice]: Duplicate volume name 'root' detected and renamed to 'root(1)'
Mon Jun 28 12:27:37 EEST [netapp: wafl.vv.regen.FSID:notice]: For flexible volume 'testi' (created via a split of a formerly mirrored-aggregate), regenerated FSID (2731bba4) host 0.
Mon Jun 28 12:27:37 EEST [netapp: wafl.vv.rename.dup:notice]: Duplicate volume name 'testi' detected and renamed to 'testi(1)'
Split of formerly-mirrored aggregate aggr0 completed, new aggregate aggr99 created.
Mon Jun 28 12:27:38 EEST [netapp: lun.newLocation.offline:warning]: LUN /vol/testi(1)/lun17 has been taken offline to prevent map conflicts after a copy or move operation.


Eikä siinä muuta. Kannattaa tietysti tarkistaa, että kaikki toimii ok tuon jälkeen.

Jossain vaiheessa pistän infoa, miten peilaus rakennetaan uusiksi.

UPDATE:

Tämä uusi Aggr99 kannattaa ehdottomasti pistää offline tilaan, ennenkuin edes miettii metroclusterin takasnostamista, tai kaapeleiden yhdistämistä niin, että netapp voi nähdä toisensa. Jos tätä ei tee, niin on mahdollisuus, että netapp jossain vaiheessa panikoi.

Zimbra: lista kaikista alias domaineista

Enpä löytänyt mitään keinoa, millä zimbrassa saisi listattu kaikki alias domainiksi määritellyt domainit, joten ainoa millä sen jotenkin järkevästi sai oli ldapsearch:

Tyyliin:

/opt/zimbra/bin/ldapsearch -H ldap://ldap.testi.fi:389 -w salakala -D uid=zimbra,cn=admins,cn=zimbra -x "(&(objectClass=zimbraDomain)(zimbraDomainType=alias))" | grep ^#

Saa tulosteeksi tyyliin:

# testi.fi


LDAP salasanan saa esille:


zmlocalconfig -s ldap_root_password

Linux: webdav (pikainen käyttöönotto)

Pikainen ohje, miten webdavin saa toimimaan Debianissa. Tää on ihan HTTP:n päällä, mutta saman voi väkertää HTTPS:n päälle jos tuntuu siltä.

Lisätään apachen modulit:

[130 root@locutus ~]# a2enmod dav_fs

Considering dependency dav for dav_fs:

Enabling module dav.

Enabling module dav_fs.

Run '/etc/init.d/apache2 restart' to activate new configuration!

[130 root@locutus ~]# a2enmod dav_lock

Enabling module dav-lock.

Run '/etc/init.d/apache2 restart' to activate new configuration!

Käynnistetään apache uusiksi:

[root@locutus ~]# /etc/init.d/apache2 restart

Luodaan hakemisto, mikä jaetaan:

[root@locutus /var/www/borgship]# mkdir web

[root@locutus /var/www/borgship]# chown www-data:www-data web

[root@locutus /var/www/borgship]# chmod 777 web

Tehdään käyttäjätunnus-tiedosto ja käyttäjätunnukset, sekä laitetaan tiedoston oikeudet kuntoon:

[root@locutus /var/www/borgship]# cd web 

[root@locutus /var/www/borgship/web]# htpasswd -c passwd.dav toni

New password: 

Re-type new password: 

Adding password for user toni

[root@locutus /var/www/borgship/web]# htpasswd passwd.dav borgship.net\\toni

New password: 

Re-type new password: 

Adding password for user borgship.net\toni

[root@locutus /var/www/borgship/web]# chown root:www-data passwd.dav 

[root@locutus /var/www/borgship/web]# chmod 640 passwd.dav 

[root@locutus /var/www/borgship/web]# 

Muokataan sivuston asetuksia:

[root@locutus /var/www/borgship/web]# vi /etc/apache2/sites-available/borgship.net

Lisää rivit:

        Alias /webdav /var/www/borgship/web


        <Location /webdav>
           DAV On
           AuthType Basic
           AuthName "webdav"
           AuthUserFile /var/www/borgship/web/passwd.dav
           Require valid-user
           <LimitExcept GET PUT HEAD OPTIONS POST>
              Require valid-user
           </LimitExcept>
       </Location>

Tallenna ja restarttaa taas apache.

Testataan:

[root@locutus ~]# cadaver http://borgship.net/webdav/           

Authentication required for webdav on server `borgship.net':

Username: toni

Password: 

dav:/webdav/> ls

Listing collection `/webdav/': succeeded.

        passwd.dav                            82  kesä   22 20:06

dav:/webdav/> 

Sitten tän voi vaikka ubuntussa mounttaa Places -> Connect Network ja saa levyn jaettua.

Redhat: prosessin lisääminen käynnistykseen

Skripti pitää olla paikallaan /etc/init.d/ hakemistossa (redhatissa init.d on symlink /etc/rc.d/init.d)

esim: 

[root@dns /etc/rc.d/init.d]# ls -ld pdns

-rwxr-xr-x 1 root root 2735 Jun  3 14:30 pdns

Kun tiedosta katsoo, skriptin alussa on jotain tyyliin:

# chkconfig: - 80 75

# description: PDNS is a versatile high performance authoritative nameserver

Siinä kerrotaan miten chkconfig ottaa runlevelit ja missä vaiheessa prosessi käynnistetään bootissa.

listaa käynnistysprosessit:

#% chkconfig --list 

Sitten lisätään ks. prosessi mukaan:

#% chkconfig --add pdns

#% chkconfig on pnds

#% chkconfig --list pdns   

pdns           0:off 1:off 2:on 3:on 4:on 5:on 6:off

Jos vaikka halutaan, että pdns käynnistyy vain init-level 3:lla, voidaan sanoa:

#% chkconfig --levels 245 pnds off

VMware: Video card RAM

Tuli tänään tämmöinen virhe, kun VMotion siirtää konetta:


Insufficient video RAM. The maximum resolution of the virtual machine will be limited to 1176x885 at 16 bits per pixel. To use the configured maximum resolution of 2360x1770 at 16 bits per pixel, increase the amount of video RAM allocated to this virtual machine by setting svga.vramSize="16708800" in the virtual machine's configuration file.


Katselin koneita läpi, niin ilmeisesti jos hardware version VM:ssä on vielä 4, niin se pistää Video RAM:ksi 4MB, kun taas HW-version 7 koneet ovat automatic asetuksilla. Ongelmasta pääsee, kun laittaa ne koneet automatic asetukselle. 


Näytti olevan KB siitä: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1014593

esxtop

Tuosta SIOC-jutusta tuli mieleen, että näin voi katsoa niitä koneiden latensseja:

#% esxtop


: paina v (disk VM)
: paina f (add more fields)
: paina j (LATSTATS/cmd = Overall Latency Stats (ms)) -- ehkä myös k, l, m (riippuu mitä haluaa nähdä)

sitten siellä näkyy DAVG/cmd, josta voit nähdä latenssiaikoja.

Hyvä ohje esxtopin saloihin: http://communities.vmware.com/docs/DOC-9279

Netapp:n tulevaisuus

Ihan kiintoista artikkeli Netappin tulevaisuudesta. Itse en näe kauhean pahana, jos joku firma keskittyy tekemään yhtä asiaa hyvin.

linkki: http://siliconangle.com/blog/2010/06/17/why-netapp-must-seek-acquisition/

Viikon linkit #1

Jotain hyviä linkkejä viikon varrelta:

• ks. linkissä kerrotaan vähän miten Vspeheren tulevassa (ehkä 4.1:ssä) Storage IO Control (SIOC) toimii. Käytännössä siis valvotaan latenssiaikoja ja kun se ylittää tietyn raja-arvon, aletaan priorisoimaan IO:n käyttöä eri koneiden välillä. Ideana on kuitenkin suojata kriittisiä järjestelmiä niin, että ne saavat enemmän IO:ta. http://vpivot.com/2010/05/04/storage-io-control/ ja hyvä youtube video: 
  
  
• "hauska" Netapp/EMC asiakascase vertailu Dan Weissin sivulla
• EMC:n VPLEX:istä Scott Loven blogista: http://blog.scottlowe.org/2010/06/07/a-deeper-look-at-vplex
• Seamicro julkaisi hienon palvelimen.. sähkönkulutus on melko pientä: http://vmblog.com/archive/2010/06/15/seamicro-unveils-revolutionary-x86-server-slashing-power-and-space-by-75-percent.aspx

http debuggausta

Oli jännä ongelma, kun ironport esti videon näkymisen video.nhl.comista. Mitään näkyvää syytä ei näkynyt,

mutta kollega antoi hyvän vihjeen, niin tsharkilla saikin näkyviin helposti mitä ironport blokkaa.

tshark -R "http.response.code == 400 or http.request or http.response.code == 403"

http:n status koodit lötyy vaikka tästä: http://www.w3.org/Protocols/HTTP/HTRESP.html

Ironport: AsyncOS 7.1 uudet ominaisuudet

Ironportin email plattiksen jotain uusia ominaisuuksia (ainakin osa):

• DLP (Data Loss Prevention) - tähän jotain uutta wizardia tulossa. DLP ei vaan oikein vielä istu Suomen markkinoille, niin kiinnostus ei ole kauhean suuri, ainakaan henk. koht.
• No Authentication Envelopes - Eli ilmeisesti tällä voidaan jatkossa lähettää kryptattuja maileja niin, että vastaanottajan ei tarvitse autentikoitua. Erona on se, että maileihin ei voi ilmeisesti vastata / lähettää eteenpäin.
• TLS
• Järjestelmässä voidaan tehdä sertifikaatti pyynnöt
• Jotain uusia debuggaus työkaluja (cli-komennot: tlsverify, hoststatus)
• Järjestelmässä voi olla useampi sertifikaatti (per Listener)
• SPF:n voi pistää päälle jo Listerneriin ja tiputtaa/hyväksyä mailit jo sillä tasolla (säästääkseen resuja)
• Content filters: add log entry, add message tag
• Retry Delivery -nappi GUI:ssa
• Shutdown/Suspend; GUI:sta näkee / voi laittaa palvelun suspend tilaan
• Muuta: packet capture (tekee pcap -fileitä, voi sitten kattella vaikka wiresharkilla), accesslistat ilmeisesti admin puolen hallintaan

Muuta. Ironportilta tuli viestiä, että kannattaa kiinnittää huomiota kuinka suuri SPAM viestien skannauskoko on, koska kuulema on ollut havaittavissa, että spammaajat yrittävät ohittaa järjestelmiä tekemällä suurikokoisia viestejä. Tietysti mitä isompi tuo on, sitä enemmän se voi vaikutata suorituskykyyn.

MPLS for dummies

Nanog #49:stä poimittu

http://www.nanog.org/meetings/nanog49/presentations/Sunday/mpls-nanog49.pdf

Nexus 7k muistiinpanoja

Nexus 7k kurssilla. En ole mikään verkkoihme, mutta jotain muistiinpanoja.

• Mallit 7010 / 7018 (7009 tulossa -> puolikas 7018)
• Paljon 10G portteja, paljon kapaa (skaalautuu 15-17Tb)
• FCOE tulossa, 5k tukee sitä jo nyt
• MPLS tulossa, en tiedä millä featureilla
• Service cardit tulossa myös, joskus
• lossless, eli ilmeisesti tarkoitetaan, että esim. paketteja ei huku, sen ei pitäisi koskaan olla alhaalla
• SUP:t kahdennettu (stateful)
• Kahdella SUP:lla voi tehdä hitless päivityksen. Kaikki softat yhdessä imagessa. Linjakortit se päivittää kortti kerrallaan (ei koko laitteen boottausta)
• prosessit voi olla päällä tai pois (esim. ospf/bgp) -> ei vie turhaa resuja
• config verification 
• Omat "ILO" interfacet (CPM -portti), jotta voi etäboottia
• VDC (virtualisointi) -> tällä hetkellä mahdollisuus tehdä 4 täysin erillistä "reititintä", tosin 1 niistä on admin VDC, joten 3 käytännössä. Haittapuolena on se, että per VDC pitää aina varata omat portit, myös uplink.
• online diagnostic -> valvoo järjestelmää -> lähettää vikailmoituksia
• 40/100G ready
• Control plane / Data-plane ovat erillisiä
• 7010:ssä oli edestä takaa ilmanvaihto, kun taas 7018:ssa se oli sivuilta. 
• 32 porttinen 10G kortti. 1:4 oversubscription (muistaakseni). Neljän portin pareista voidaan tiputtaa 3 pois, jolloin koko kytkimessä voisi olla 8 10G porttia, jolle on dedikoitu 10G yhteys (per portti)
• Tulossa myös 8 porttinen 10G kortti juurikin edellistä varten
• Hienot (minusta?) jonotus/bufferointi ominaisuudet. Kun paketti tulee sisään, kysytään SUP:lla olevalta ASIC:lta (Arbirator muistaakseni) missä kaverin jonossa on vapaata. Per moduli oli aina monta jonoa. Tai jotain sinnepäin, pitää katsoa tarkemmin uudestaan, jos tarve :)
• NX-OS:ssa voi sanoa "ip address 1.2.3.4/32" tai ACL:ssä permit jotain 1.2.3.4/32 (yay)

Lisää vielä... huomenna ehkä sen konffauksesta jotain.

Updatea vähän tältä päivältä:

• vPC vaikutti ihan toimivalta systeemiltä. Se käytännössä vaatii 10G linkit aina kahden nexuksen väliin ja ilmeisesti vähintään yhden keepalive linkin. Ainoa mikä oli vähän epäilyttävää on, että jos tulee split brain, niin ilmeisesti molemmat ovat silti aktiivisia ja no.. silloin voi vähän homma ns. pissiä. Toinen mikä voi olla haaste, että konfiksesta voi tulla aika sekava, jos tän tekee 4 purkilla reduksi. Tiedä sitten tuleeko enemmän inhimillisiä virheitä vaan vPC:n takia.
• OTV mikä on tulossa jossain vaiheessa käytännössä levittää L2:n L3:n yli vaikka eri datacenteriin. Mä en kyl keksinyt mikä tän hyöty nyt sitten ois ja missä sitä vois käyttää, koska esim. jos siirrät palvelimen VMotionilla konesalista1 konesaliin2, niin sun default gw jää konesaliin 1 ja paketit viuhuu sitten sinne joka tapauksessa. Ope sano, että Cisco on tuomassa LISP (Locator/ID Separator Protocol), joka ilmeisesti toisi tähän reitityspuoleen jotain lisää. Saapa nähdä.

Kurssilla ei nyt mitään ihmeellistä konffailtu. Pistän VDC:n konffaamisen jossain vaiheessa, mutta muutenpa kaikki on aika perusjuttuja jos verkkoja säätää.. kai :) vPC:tä ei voi ees tehdä Ciscon labrassa, kun heillä ei ollut 10G kortteja.

NX-OS kyllä oli aika mukavan tuntuinen.. Oli linuxista tuttuja komentoja ja muutenkin aika linuxmainen koko OS.

Update #2:

• Selkeydeksi Data Center Bridging nimeämisestä. DCB on virallinen IEEE nimi, mutta muita on Data Center Ethernet (Ciscon käyttämä, poistumassa), FCIP, CCE (Converged Enhanced Ethernet), Unified Fabric, Lossless Ethernet 

VMWare: VSphere Update 2

Update 2 julkaistu:

Release notesit löytyy:
ESX: http://www.vmware.com/support/vsphere4/doc/vsp_esx40_u2_rel_notes.html
ESXi: http://www.vmware.com/support/vsphere4/doc/vsp_esxi40_u2_rel_notes.html
VCenter: http://www.vmware.com/support/vsphere4/doc/vsp_vc40_u2_rel_notes.html

NFS:stä kun tykkään, niin siellä oli mielenkiintoinen feature:



Enhancement of the esxtop/resxtop utility— vSphere 4.0 Update 2 includes an enhancement of the performance monitoring utilities, esxtop and resxtop. The esxtop/resxtop utilities now provide visibility into the performance of NFS datastores in that they display the following statistics for NFS datastores: Reads/s, writes/s, MBreads/s,MBwrtn/s, cmds/s, GAVG/s(guest latency).

Ironport: DKIM käyttöönotto

Ohjeita vähän miten DKIM saadaan käyttöön Ironportissa, jos sille tarve on.
En ota sen kummemin kantaa sen hyödyistä / haitoista, käyttää ne jotka sitä haluavat.
DKIM:stä on tietoa netissä, joten googlettaa vaan jos haluaa perusteita lueskella.

Vaihe 1: Luodaan Signing Key. Klikkaa Generate nappia.

Vaihe 2. Tehdään profiili. Kuvasta näkee vähän mitä kenttiä on hyvä täyttää.

Vaihe 3. Luodaan DNS Record (Paina Generate -nappia)

Pompsahtaa ruutuun, jossa klikataan vain Generate ja saadaan DNS-tietue valmiiksi.

Laitetaan DNS:ään generoitu DNS-tietue:

borg.ship._domainkey.borgship.net. IN TXT "v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDgDb7SpyjXokmKtlEqJKBE/j+bX5kklTP8msJ16vSpNNV8VWL48xZImABmbMoaHi96kTihVsLMFRz5V0ZuOOnhUzZaUUV2zzBjIpSZ506gqiZduHT4P/j282P+eENIq5KoFOIdsReXmwARtt7RAd11dAfh11yxmu6NSRdB7ORJ9wIDAQAB;"


Odotetaan, että DNS tieto leviää, jonka jälkeen Domain Profiles -sivulla voi käydä testaamassa toimiiko DNS. Jos ei toimi, DNS tietueessa on jotain vikaa.

Kun DNS on ok, laitetaan DKIM päälle haluttuu Mail Flow Policyyn, tyyliin:

Tats it.. Sitten vaan testipostia lähettämään.

Vastaanottalla näkyy headerissa seuraavanlainen kenttä, jos DKIM on toiminut:

DKIM-Signature: v=1; a=rsa-sha256; c=simple/relaxed;
  d=borgship.net; i=toni@borgship.net; q=dns/txt;
  s=borg.ship; t=1276237097; x=1307773097;
  h=received:message-id:date:from:user-agent:mime-version:to:
   subject:content-type:content-transfer-encoding;
  z=Received:=20from=20toni.fi.sn.net=20(HELO=20[62.236.35.2
   16])=20([62.236.35.216])=0D=0A=20=20by=20smtp21.tdc.fi=20
   with=20ESMTP=3B=2011=20Jun=202010=2009:18:17=20+0300
   |Message-ID:=20<4C11D522.8020407@borgship.net>|Date:=20Fr
   i,=2011=20Jun=202010=2009:18:10=20+0300|From:=20=3D?ISO-8
   859-1?Q?Toni_M=3DE4=3DE4tt=3DE4?=3D=20
   |User-Agent:=20Mozilla/5.0=20(X11=3B=20U=3B=20Linux=20i68
   6=3B=20en-US=3B=20rv:1.9.1.9)=20Gecko/20100423=20Thunderb
   ird/3.0.4|MIME-Version:=201.0|To:=20toni.maatta@tdc.fi
   |Subject:=20testiposti|Content-Type:=20text/plain=3B=20ch
   arset=3DISO-8859-1=3B=20format=3Dflowed
   |Content-Transfer-Encoding:=208bit;
  bh=sTDP/STWqQed22gkFytNkl02nfXuticV9sO1oirn/fI=;
  b=JkjA4yyILOrPCbkVCqwPMTBYgNh1fWY31eWj7H//xiLrt6CJBPaPboam
   1luGHRO/sVLeDNgmaEZyoX+kFjMw3HreUzo+ITCfw0TSjeNBoWQtMKV6R
   JNoKvsDZE/Q8/KZn6NUyMi/yZaYlpgWlqHsOeJKD+38dVT1F+2sapaKlR
   w=;