X

News, tips, partners, and perspectives for the Oracle Solaris operating system

ASM Scoped Security - Ein Realistisches Beispiel

Wenn man, z.B. auf SuperCluster, mehrere Instanzen der Grid Infrastruktur (gerne als RAC Cluster bezeichnet) betreibt, die die selben Exadata Storage Server (oder kurz Zellen) verwenden, ist es ratsam, ASM Scoped Security zu verwenden.  Selbst wenn es, wie z.B. bei mehreren Mandanten, keine Sicherheitsgruende dafuer gibt, kann man auf diese Weise immer verhindern, dass der Admin des einen Clusters versehentlich die Diskgruppe des anderen Clusters verwendet.  Als einfach umzusetzende Sicherheitsmassnahme ist das daher immer eine gute Idee.

Natuerlich gibt es fuer dieses Feature der Storage Zellen gute Dokumentation.  Allerdings steckt auch hier der Teufel im Detail, daher hier ein vollstaendiges Beispiel, wie man das macht:

  1. Den entsprechenden Cluster anhalten.  Kommando: "crsctl stop crs" auf allen Cluster Knoten.
  2. Einen Schluessel fuer den Cluster erzeugen
    Das macht, auf irgend einer Storage Zelle, das Kommando
    "cellcli -e create key".  Heraus kommt ein ASCII String, der als Schluessel zu verwenden ist.  Diesen Schluessel notiert man sich irgendow.  In diesem Beispiel verwende ich den Schluessel '9e9a606a461a1abc6af43626e85af3b7'.
  3. Nun denkt man sich einen eindeutigen Namen fuer den Cluster aus.  In diesem Beispiel verwende ich dafuer "marsc1" - der erste Cluster, der auf mars laeuft.
  4. Nun verknuepft man diesen Namen mit dem Schluessel.  Das muss auf jeder beteiligten Storage Zelle mit cellcli gemacht werden:
    CELLCLI> assign key for 'marsc1'='9e9a606a461a1abc6af43626e85af3b7'
  5. Hier kommt der komplizierteste Teil.  Der eindeutige Name muss nun jeder einzelnen Griddisk, die unser Cluster verwendet, zugewiesen werden.  Leider ist die Kommandozeile von CELLCLI hier nicht wirklich hilfreich.  Ich habe das so geloest:
    1. Auf jeder Zelle eine Liste aller Griddisks anlegen, die zu marsc1 gehoeren.  Mit CELLCLI:
      spool /tmp/disks
      list griddisk where asmdiskgroupname='DATAC1' attributes name
      list griddisk where asmdiskgroupname='RECOC1' attributes name
    2. Jetzt enthaelt /tmp/disks auf jeder Zelle eine Anzahl Zeilen aehnlich wie diese:
               DATAC1_CD_00_marsceladm04    
               DATAC1_CD_01_marsceladm04   
               DATAC1_CD_02_marsceladm04   
               DATAC1_CD_03_marsceladm04   
    3. Jetzt aendert man diese Datei in eine Kommando-Datei fuer CELLCLI.  Ich habe dafuer vi und awk verwendet, aber es geht sicher auch anders.  Das Ergebnis sah bei mir dann so aus:
      alter griddisk DATAC1_CD_00_marsceladm04 availableTo='marsc1'
      alter griddisk DATAC1_CD_01_marsceladm04 availableTo='marsc1'
      alter griddisk DATAC1_CD_02_marsceladm04 availableTo='marsc1'
      alter griddisk DATAC1_CD_03_marsceladm04 availableTo='marsc1'
    4. Jetzt laesst man dieses Script auf jeder Zelle laufen.  Natuerlich gibt es fuer jede Zelle ein eigenes Script!
      # cellcli < script
    5. Und jetzt noch nachsehen, ob es geklappt hat, wieder mit CELLCLI:
      list griddisk attributes name,availableTo
  6. Damit nun die Cluster-Knoten auf diese Griddisks zugreifen koennen, brauchen sie natuerlich das Name/Schluessel-Paerchen.  Das legt man unter Solaris auf jedem Knoten in der Datei
    /etc/oracle/cell/network-config/cellkey.ora ab.
    Meine sieht so aus:
    key=9e9a606a461a1abc6af43626e85af3b7
    asm=marsc1
  7. Nun noch die Cluster-Knoten neu starten:
    crsctl start crs

Das sollte alles sein.  Um zu pruefen, ob es geklappt hat, kann man in einem anderen Cluster mit dem Kommando "asmcmd lsdg --discovery" nachsehen, welche Griddisks verfuegbar sind.  Die eben geschuetzten sollten nicht mehr darunter sein.

Nun muss man das Ganze natuerlich fuer alle anderen Cluster wiederholen.  Am Ende hat man Cluster mit exklusivem Zugriff auf die eigenen Platten.  Ganz ohne die Gefahr von unabsichtlichem oder gar boesswilligem Zugriff unberechtigter.

Ein Tool, das ich zur Arbeit an den vielen Zellen sehr hilfreich finde, ist uebrigens "cssh", eine 1-N Kommandozeile die in neueren Versionen von Solaris enthalten ist.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha