Tag Archief van: storage

QNAP storage box 802.3ad, LACP en Cisco (of dergelijke merken)

/0 Reacties/in /door

Vandaag leuk mogen spelen met een QNAP storage box. Schitterend ding voor zover ik er echt veel mee heb kunnen doen. In ieder geval een leuk apparaat om tijdelijk wat speel VM’s op te plaatsen die vanaf de VMWare omgeving gestart moeten kunnen worden maar de kosten van een SAN omgeving niet waard zijn.

Maar, zo’n QNAP met dubbele NIC wil je soms in een 802.3ad port-channel plaatsen, let op standaard gaat dit niet goed (standaard Cisco etherchannel). Daarom hieronder een voorbeeld config:

!
interface GigabitEthernet1/0/4
 description QNAP-01
 switchport access vlan 210
 switchport mode access
 channel-protocol lacp
 channel-group 13 mode active
 spanning-tree portfast
end

!
interface GigabitEthernet2/0/4
 description QNAP-01
 switchport access vlan 210
 switchport mode access
 channel-protocol lacp
 channel-group 13 mode active
 spanning-tree portfast
end

!
interface Port-channel13
 description QNAP
 switchport access vlan 210
 switchport mode access
 spanning-tree portfast
end

Hyper-V cluster shared volume iscsi errors and event ID 20 and event ID 34

/0 Reacties/in /door

De gehele avond besteeds aan e.e.a. aan problematiek inzake een Hyper-V Cluster Shared Volume omgeving. De feiten:

Stroomuitval
Alles is herstart en er blijven problemen. Een node opbrengen helpt niet, meerdere nodes ook niet. Allemaal komen ze met dezelfde events 20 en 34

Event 20:
Connection to the target was lost. The initiator will attempt to retry the connection.

Event 34:
A connection to the target was lost, but Initiator successfully reconnected to the target. Dump data contains the target name.

Wat kwam er nog meer voorbij (sorry,  het is 03:30 ’s nachts) o.a.:

STOP 0x0000009E zie hiervoor:
https://blogs.technet.com/b/askcore/archive/2009/06/12/why-is-my-2008-failover-clustering-node-blue-screening-with-a-stop-0x0000009e.aspx

Dit zegt feitelijk “Alles wijst naar het cluster, maar het bevind zich op een diepere laag”. Als we dit combineren ga je ervanuit dat e.e.a. met elkaar te maken heeft.

Verder hadden we nog de volgende error:
“Cluster resource ‘Cluster Disk 1’ (resource type ”, DLL ‘clusres.dll’) either crashed or deadlocked”

Maar dit gaat “veel dieper” dan de laag waarop ik het vermoeden heb (had ;)).

Uiteindelijk was alles te herleiden naar de stroomuitval. De iSCSI switches waren niet gevoed en die vielen direct uit. Wat is er gebeurd, de switches zijn de config’s verloren en de “Jumbo frames” setting is verloren gegaan. Je raad al wat er gebeurt, de verbindingen gaan staan klapperen en dus “disken” ook. Wel contact, geen contact, enz. enz. De hosts stonden op 9000, het SAN ook, behalve de switches…..

Aanpassen en alles liep weer :)

Data partitie vergroot maar Windows explorer geeft nog de verkeerde grootte aan ten opzichte van Disk Manager

/1 Reactie/in /door

Helemaal onderaan de vraag nog een aantal keer in het engels opgesomd. Hopelijk vinden mensen toch datgeen dat ze nodig hebben, ondanks dat het NL is.

Ik heb onderstaand eerder met college Niels bij de hand gehad bij een van onze klanten. Omdat het daar om een nieuwe installatie ging, en DELL ons niet verder kon helpen, hebben we onderstaand opgelost door een nieuw lun te maken en opnieuw te beginnen (deze was immers leeg en op een gegeven moment moet je wat).

Nu vandaag dus weer, tsja, 2x is teveel van het goede dus nu maar aanpakken. Ohja, ik had ook geen andere keus ;)

Wat is het geval, je hebt een bestaande partitie, deze vergroot je, extend je, of je bied hem anders aan waardoor de ruimte groter word. Denk aan dit laatste het LUN vanuit het san ophogen of de lokale RAID set uitbreiden met meer disken.

Wat schetst je verbazig? Diskmanager alsmede diskpart geven aan de het nieuwe volume toch echt de grootte is die je gekozen hebt, maar helaas, Windows Explorer is het hier niet mee eens. Er kan ook niet meer data op dan dat Explorer aangeeft. In de situatie van vandaag gaat het om 20GB wat “weg” is. Het is er wel, maar niet beschikbaar.

Hierbij nog een screenshot van “na”, helaas heb ik er geen een meer waarin je in Explorer echt een te kleine disk zie en in Partition manager een grotere.

 

Dit komt door het “extend” commando via Diskpart, of welke andere manier dan ook (diskmanager en kiezen voor extend is hetzelfde). Wat (kan) er gebeuren? De disk word vergroot maar het “filesystem” niet. Wat je ook doet, checkdisk, defrag, lun ontkoppelen en koppelen, maakt niet uit. De disk word niet “groter”.

Simpelgezegd, de storage is zichtbaar, en het volume (welke je overigens extend) is ook 80 GB (dit kan je checken met diskpart) alleen het “Filesystem” wat erop draait (b.v. NTFS) heeft dit niet door (ik denk overigens dat het puur een NTFS issue is). Dit houd in dat eigenlijk het “filesystem” niet extend is.

Met andere woorden. We moeten het filesystem extenden, dit doe je als volgt:

Start een command prompt. En ga los:

Diskpart (command line, built in, disk partition manager)

List volume

                Je krijgt nu een overzicht van de volumes, geef het volume aan waar het om draait

Select volume (number)

En dan nu het magische commando

Extend filesystem

Tadaaaaa!!!

Alle ruimte is bruikbaar.

Lees meer

EMC SAN nieuwe “features” FAST sub lun, Fast Cache en Lun compressie 3/3

/0 Reacties/in /door

In navolging op de twee voorgaande delen, hierbij het laatste deel.

Block Compression

In het Nederlands, blok compressie. Zoals de naam al aangeeft, compressie op blok niveau.  Een groot verschil hierin is dat het _geen_ de-duplicatie is en ook geen data compressie. Hieronder een samenvatting van deze twee in een notendop:”

“De-duplicatie” elimineert dubbele opslag van bv. hetzelfde bestand. Als één exact zelfde bestand 2x voorkomt, kan je het 1x opslaan en de 2x naar de opgeslagen versie verwijzen. Even heel erg plat, maar daar hebben we het over met “de-duplicatie”.

“Compressie” daarentegen “comprimeert” zogeheten “data”. Denk daarbij aan een document welke gecomprimeerd word. Veel gebruikte programm’s zijn WinZIP en WinRAR.

Block compressie zit dieper. Wat er gedaan word is de “ruwe” data welke in bepaalde “Blok grootte” weggeschreven word op disken gecomprimeerd word. Hiermee kan het SAN altijd compressie uitvoeren. Bij de-duplicatie moeten er dubbele files zijn, compressie is normaliter niet mogelijk op een SAN. EMC claimt met hun technieken tot 50% compressie te kunnen halen en liggen daarmee 20% hoger dan claims met de-duplicatie. De tijd zal het leren…

EMC SAN nieuwe “features” FAST sub lun, Fast Cache en Lun compressie 2/3

/0 Reacties/in /door

In navolging op het vorige artikel, gaan we hier verder met de “nieuwe” features.

Fast-cache

Een ander nieuw aspect is: “Fast-cache”. Met de komst van SATA is het nog interessanter om goed te kunnen “cachen”. Als je het vorige voorbeeld neemt (en ik ga nu een nieuw voorbeeld schetsen, zet nooit een database op SATA tenzij dit weloverwogen gebeurd, bv. archivering) kan je de database van 100GB op SATA zetten, als die actieve 10GB maar HEEL SNEL te benaderen is. Dit kan o.a. gerealiseerd worden met Caching, maar een SAN heeft maar een bepaalde hoeveelheid cache on-board waar je het mee dient te doen. Dit veranderd met de komst van Fast-cache. Fast cache stelt een SAN in staat om EFD (Enterprise Flash Disk=SSD) disken te gebruiken voor caching. Simpel gezegd plaats je EFD disken in het SAN en hiermee breid je de on-board cache van bv. 2GB uit naar 100GB (kan tot wel 2TB). Dit houdt in dat de gehele database in de cache kan komen te draaien. We hebben het hier over 1000’en IOPS.

Morgen het vervolg en sluitstuk 3/3 inzake Lun-Compressie

EMC SAN nieuwe “features” FAST sub lun, Fast Cache en Lun compressie 1/3

/0 Reacties/in /door

Van de week was ik weer lekker met verschillende type SAN oplossingen in de weer, waaronder een CX4-120. Naast de standaardwerkzaamheden kwam er toevallig ook wat voorbij wat mijn aandacht trok. En dat is:

FAST Sub-lun (Fully Automated Storage Tiering)
FAST Cache (Fully Automated Storage Tiering – Caching)
LUN Compression

Fast Sub-lun (Fully Automated Storage Tiering)

Mijn belevenis, een van de sterkste features van een 3PAR is het werken met “Chuncks”. Chuncks houd in dat je niet meer werkt met disken, raid groups, en dergelijke. Nee, de data word los getrokken van de storage, je geeft alleen aan hoe je dit aan wil bieden. Het zij via iSCSI of Fiber Channel, en dat is alles. Wat is hierbij het voordeel? nog niets, maar wel als je dit combineert met “chunks” (datablokken) die automatisch verplaatst kunnen worden naar de “Tier” die hierbij past.

Voordat we verder gaan, eerst en overzicht van welke “tiers” (lagen) er zijn:

Tier 0 = SSD (Solid State Disk)
Tier 1 = FC Disk
Tier 2 = SATAII disk
Tier 3 = offline media

Zoals te zien is, is “Tier 0” de snelste media waarbij “Tier 3” (vaak offline) de traagste media is. Voor een overzicht van de verschillende snelheden per “Tier” kan je hier terecht: http://en.wikipedia.org/wiki/IOPS

Terugkomend op de “Chuncks”, als we het kort samenvatten krijgen we het volgende. Nu de data in “Chuncks” verdeeld is, zou het geweldig zijn als deze “Chunks” automatisch verplaatst worden naar de storage waar deze het beste tot zijn recht komt. Een database van 100GB kan in “Chuncks” worden opgedeeld, waarbij de 10GB die echt actief is op Tier 0 komt, de 20GB die minder actief is op Tier 1 waarbij de overige 70GB op Tier 2 komt. Hierbij haal je het optimale uit de storage die je tot je beschikking hebt en hoef je niet achteraf te schakelen. Denk hierbij dat een database in test op SATA goed werkte, in productie ook, maar naarmate het proces binnen het bedrijf veranderd er meer vraag is en de performance vereiste omhoog gaan. Het SAN kan dan zelf acteren in de vraag naar snelheid. Het tegenovergestelde kan ook plaatsvinden, die database server die nog op snelle storage stond zal automatisch (na uitfasering b.v.) verplaatst worden naar tragere storage.

Word vervolgd….. (volgende week)