Dissenyat per fallar

English: Alan Shepard in capsule aboard Freedo...

Anglès:. Alan Shepard en la càpsula Freedom 7 a bord abans del seu llançament-1961 Alan Shepard es va convertir en el primer americà en l'espai el 5 de maig 1961 es va posar en marxa a bord del seu Mercury-Redstone 3 coet anomenat Freedom 7-el vol suborbital va durar 15 minuts. (Foto: Wikipedia)

Estic escrivint això una mica per la meva dona i els meus amics no tècnics. Com jo estava pensant a través d'aquesta idea es va acudir que no és especialment tècnica, i és una gran manera d'explicar el que vaig passar gran part del meu temps a fer quan estic en realitat el disseny de solucions.

Recentment la meva dona i els meus telèfons han trencat en diverses maneres, va deixar caure la seva i que mai ha estat el mateix des de llavors, la meva només tenia una mica d'un error de maquinari fiable i tractant de solucionar ho feia pitjor. La tecnologia que comprem és generalment elaborat pel proveïdor de maquinari més barat, amb la tecnologia de més baix cost dels productes bàsics (no sempre és així, però en gran part cert). La producció en massa redueix els costos, així que no prendre dreceres i la reducció de la redundància (diversos components que hi són únicament per fer-se càrrec quan un falla).

A la vida familiar en general la majoria de nosaltres no es molesten amb la redundància, alguns de nosaltres pot tenir més d'un PC d'escriptori o portàtil, però la majoria de nosaltres només tindran un telèfon personal, un televisor de pantalla gran, un jugador Blueray, etc etc Comprem els productes bàsics i acceptem que és una mercaderia i propensos a les falles. Alguns de nosaltres no s'adonen d'això i es molesten quan la tecnologia falla (potser molts de nosaltres no s'adonen això!), Però quan es recorda que la tecnologia que tenen no és necessàriament la millor (el millor és car), però el més barat, et donaràs compte de per què és tan propensa al fracàs. Aquesta és la raó per la indústria d'assegurances tecnologia per a la llar és tan fort!

DevOps vs TI-Ops

He passat els últims mesos vigilant de prop les borses de treball, i degut a la meva fons de desenvolupament web que es marquen per als treballs de desenvolupament. És interessant que la gran majoria de les funcions de desenvolupament sembla ser llançat com DevOps papers. Inicialment això té el meu interès com Jo estaria molt interessat en fer un paper DevOps (les meves habilitats dev estan oxidats, però puc fer costat Ops força bé). Però sembla que la majoria dels papers DevOps són simplement només papers de desenvolupament amb una mica de gestió de configuració inclosos, i la gestió de configuració és el codi relacionat, no en la infraestructura relacionada.

Si ens fixem en la banda de les operacions de TI de les coses, aquests nois són cada vegada més involucrats en automatitzat construeix, la gestió de configuració de la infraestructura i el concepte de servidor immutable a tot arreu. El problema és que no és significatiu cross-over en l'utillatge per DevOps i IT-Ops. Si vostè està buscant alguna cosa com Xef , de titelles , de ansible o sal , un dels factors clau de decisió és ets un desenvolupador o una persona de la infraestructura. Els desenvolupadors són més propensos a entendre Github repositoris i els fluxos de treball, mentre que els nois d'infraestructura entendran més les seqüències d'ordres d'una construcció automatitzat. Amb els principals proveïdors de virtualització d'infraestructura de venir a la festa amb coses com la de VMware Application Director i el Director de Dades , així com de Microsoft App-Controller , aquest mercat s'està convertint ràpidament ocupat.

Però la pregunta clau segueix sent, ets un desenvolupador o una persona de la infraestructura? Ja sigui una persona infraestructura està construint un model del traspàs al desenvolupament, o un desenvolupador està prenent una plantilla pre-construït i l'automatització del seu codi a través de la part superior de la mateixa. Què passa amb DevOps llavors? En quin punt l'equip d'operacions d'infraestructura realment treballar en estreta col · laboració amb l'equip de desenvolupament? Potser la pregunta està més a prop: En quin punt l'equip d'infraestructura de deixar que l'equip de desenvolupament de acostar-se a la infraestructura, i en quin moment serà l'equip de desenvolupament de deixar que l'equip d'infraestructura d'estar més a prop del seu codi? Encara hi ha massa arguments en un sentit o un altre (el codi no està optimitzat per a una pila virtual, la seva infraestructura no és prou dinàmic per al nostre codi, etc, etc.)

Expliqueu Snapshots

Això sembla ser un terme de cerca més populars, així que crec que val la pena que cobreix apagat. Això està cobert en el meu antic lloc dalt sobre reserva fraccional , però vaig a cobrir les alternatives aquí també.

snap00259

NetApp instantànies solien ser bastant únic en la indústria, però el terme de la indústria perquè aquesta tecnologia és en general ara Append-on-Write / Redirect-on-Write (escriptures noves s'afegeixen al "fi", o redirigits a blocs lliures, depenent com es miri) i un bon nombre de venedors de feixos d'aquesta manera. En termes molt senzills, totes les noves dades s'escriuen en blocs nous (reduïts a zero) en el disc. Això no vol dir que l'espai d'instantànies ha de ser lògicament en la mateixa ubicació que les dades de producció, però que realment no hauria de ser un problema amb piscines en tota la creació de bandes / agregats / emmagatzematge (recollir terme proveïdor preferit). Quan es pren una instantània, la taula d'inodes es congela i es copia. Ara els punts de la taula d'inodes als blocs de dades, i aquests blocs de dades es converteixen en fixos. A mesura que el sistema de fitxers "canvis" actius blocs, aquests en realitat s'escriuen a noves ubicacions en el disc, i el que no hi ha cap sobrecàrrega a l'escriptura (els nous blocs ja es posen a zero). En altres tecnologies (no NetApp) això també és la base d'organització en nivells automatitzada, una vegada que les dades està "bloquejada" per una instantània, que serà mai sobre-escrit pel que amb seguretat pot connectar en cascada de SSD o fins i tot a SAS com el rendiment de lectura és poques vegades un problema. Ús NetApp FlashPools per augmentar això, i una instantània és un disparador perquè les dades es escalonades de FlashPools ja que mai serà "sobreescrit".

VMware Ready Temps CPU

M'ha sorprès que recentment s'ha tornat a perseguir com un problema, i una de les principals en això.

Llavors, quin és el problema? Bé, conte llarg, si vostè mor de fam seu patrimoni virtual de recursos de CPU que obtindrà problemes d'estat de llest CPU. En termes generals això és causat per 2 qüestions, que ha sobre-compromès els seus recursos de la CPU (índex de consolidació és massa alt), o les màquines virtuals són de grandària massa gran (i la seva càrrega de treball és massa alt).

VMware vSphere és molt intel · ligent amb la seva virtualització de la CPU. Per tal de permetre que múltiples màquines virtuals comparteixen el mateix espai de la CPU, són ells els horaris d'entrada i sortida. No cal dir que això passa molt ràpidament, i en general, l'única cosa que vostè notarà és que consumeixen molt poca CPU i tenen una relació molt alta de consolidació. El problema realment es produeix amb gran VMs (4 + de CPU virtual). vSphere ha de ser molt més intel · ligent sobre això, ja que la necessitat de tot vCPU a ser programat al mateix temps, o esbiaixat lleugerament (part de la col · programació relaxat en 5.0 +). La finestra d'oportunitat per programar aquests s'estreny més de CPU virtual que assigni, de manera que una màquina de 4 CPU virtual ha d'esperar 4 nuclis lògics que estigui disponible ( Hyper-Threading nuclis compten nuclis lògics com individuals), i 8 de la màquina CPU virtual ha d'esperar que 8. Com més ocupat un host vSphere és, com més temps una cua pot haver dels recursos de CPU i més difícil serà per programar tota la CPU virtual de és. Mentre que una màquina està esperant recursos de la CPU que estigui disponible, que està en un estat llest (el que significa que té la CPU per processar les transaccions, però no com no es disposa dels recursos). El co-programació relaxat vol dir que no sempre ha d'esperar a que tot vCPU de ser programat al mateix temps en nuclis físics lògics, però és una regla d'or quan es dimensiona.

Tags: , , , , Categories: Generals Etiquetes: , , , ,

Un nou començament

En primer nou post en el que, de 2-3 anys? WAFL.co.uk encara realitza admirablement i ara que m'he mudat papers m'imagino que és hora de tornar a visitar els meus vells amors. El meu laboratori llar necessita una reconstrucció i modernització, i que ha d'aconseguir documentat!

Així que m'he mogut en el gran món de por de contracte de treball basat, vaig començar el meu primer paper fa un parell de setmanes, i fins ara em va molt bé. Vull mantenir una actualització de les meves gestes, els desafiaments reals que s'enfronten els clients i comparteixen algunes de les meves reflexions genèriques. El lloc estarà menys centrada en NetApp, però encara tinc els meus arrels en l'emmagatzematge!

El meu primer paper participen una gran quantitat de reptes interessants, però hi ha alguna cosa de gran tecnologia disponible aquí també. Un fort DevOps equip (aquelles que necessiten ajuda integrant el bit Ops, no tothom?), un munt de reptes Big Data, i un projecte immediat per mirar a la creació d'una infraestructura molt més sensible, inclosos els casos en els serveis de núvol encaixar vaig començar vida com a desenvolupador web, i és genial estar de tornada en una empresa puntcom i veure com han evolucionat els reptes.

Millorat per Zemanta

NetApp debuta a petició Performance Manager

NetApp setmana passada en llibertat a petició Performance Manager Candidat 1.0 Release 1 (RC1) a tots els clients i socis de NetApp. Aquest nou programari ofereix la gestió del rendiment, solució de problemes, i la notificació d'esdeveniments per sistemes que en clúster Data ONTAP 8.2 i 8.2.1.

Performance Manager 1.0 RC1 es desplega, no s'instal · la, com un dispositiu virtual en VMware ESX o ESXi. Un dispositiu virtual és un paquet de programari creat prèviament, amb un sistema operatiu i aplicacions que s'integren programari, gestionat i actualitzat com un paquet. Aquest mètode de distribució de programari simplifica el que seria un procés d'instal · lació d'una altra manera complexa.

Després del desplegament, el dispositiu virtual basat en Linux 2.6.32 crea una màquina virtual que conté el programari de l'usuari, les aplicacions de tercers, i tota la informació de configuració preinstal · lat en la màquina virtual. Gran part del middleware dispositiu virtual està construïda principalment amb Java i inclou diversos components de codi obert - sobretot de (però no limitats a) la Apache Software Foundation, el projecte Debian i la Free Software Foundation.

Dimensionament Performance Manager es basa en una sèrie de factors: el nombre de grups de Data ONTAP en clúster, el nombre màxim de nodes en cada grup, i el nombre màxim de volums en qualsevol node d'un clúster.

Per tal de complir amb l'estatut oficial compatibilitat de NetApp, Performance Manager 1.0 RC1 requereix 12 GB de (reservat) de memòria, 4 CPU virtuals, i un total de 9.572 MHz de (reservat) CPU. Aquesta configuració qualificat compleix els nivells mínims de rendiment acceptable i configuració d'aquests valors més petits del que s'especifica no és compatible. Curiosament, l'augment de qualsevol d'aquests recursos està permès - però no és recomanable - ja que en fer-ho ofereix poc valor addicional.

De fet, segons dades de desembre de 2013 AutoSupport de NetApp, la majoria dels clients han d'esperar per implementar un únic dispositiu virtual Performance Manager; com una instància serà adequat per al 95% de tots els sistemes Data ONTAP agrupades actualment desplegats.

També és interessant observar que hi ha un bon nombre de productes de la cartera petició que proporcionen supervisió del rendiment. Així que quan anava a un producte s'adapta millor sobre un altre?

Anem a començar amb Performance Manager; aquest és el mínim comú denominador. Supervisa i soluciona els problemes profundament en el sistema Data ONTAP agrupat.

A petició de balanç ofereix la solució de problemes i l'optimització en el següent nivell - especialment en un entorn de virtualització de servidors. Supervisa clúster Data ONTAP, les màquines virtuals i hosts. Es correlaciona totes les dades mitjançant l'ús d'anàlisi de rendiment i proporciona orientació.

Finalment, a petició Insight és una solució de gestió de recursos d'emmagatzematge complet per gran complex, l'emmagatzematge, de múltiples proveïdors en entorns virtuals i físics. Els clients de NetApp afegir Insight si tenen l'emmagatzematge d'altres proveïdors, com ara EMC, HP, IBM, HDS, etc

No es requereix llicència per desplegar a petició Performance Manager 1.0 RC1. Per a les versions de servidor i navegador VMware necessaris, consulteu la eina Matriu d'interoperabilitat pàgina (IMT) en el lloc de suport de NetApp.
Tags: , Categories: Geek ONTAP Etiquetes: ,

NetApp presenta FAS8000

NetApp ha llançat avui la sèrie FAS8000, el seu més recent plataforma empresarial per a la infraestructura compartida, amb tres nous models: FAS8020, FAS8040, FAS8060 i, que substitueixen la FAS/V3220, FAS/V3250 i FAS/V6220, respectivament. Aquesta nova línia s'enviarà inicialment amb Data ONTAP 8.2.1 RC2, suportant ambdues 7-Mode o clúster Data ONTAP.

Tots els sistemes estan disponibles en configuracions ja sigui independents i HA dins d'un sol xassís. Totes les configuracions de controlador FAS8000 independents poden tenir un segon controlador (del mateix model) afegit al xassís per esdevenir HA.

El nou FAS8000 ha estat certificada amb el DS2246, DS4246, DS4486, DS4243, DS14mk4, i les safates de discos DS14mk2-AT amb IOM6, IOM3, ESH4, i els mòduls de la plataforma AT-FCX. Emmagatzematge virtualitzat de múltiples proveïdors també es pot afegir a la FAS8000 - sense un sistema dedicat V-Sèries "porta d'entrada" - amb la nova funció de programari "FlexArray".

NetApp no ​​oferirà un model FlexCache separada per a la sèrie FAS8000.

Anem a explorar els detalls tècnics de cada un d'aquests nous sistemes d'emmagatzematge.


FAS8020
El factor de forma FAS8020 3U (amb nom en codi: "Buell") està dirigit als clients de l'empresa de mida mitjana, amb càrregues de treball mixtes. Cada mòdul de control del processador (PCM) inclou un únic socket, 2.0 GHz Intel E5-2620 de processador "Sandy Bridge-EP" amb 6 nuclis (12 per HA parell), un processador Intel Patsburg-J Southbridge, i 24 GB de memòria DDR3 físic ( 48GB per HA parell).

NetApp suporta configuracions de controlador únic i dual en un sol xassís, però a diferència dels sistemes anteriors, mòdul d'expansió d'E / S (IOXM) configuracions no són compatibles. L'augment de la barreja d'alt rendiment ports a bord i la flexibilitat que ofereix el nou adaptador Objectiu 2 (UTA2) ports Unificades redueix la necessitat dels recomptes de tragamonedas més altes en la sèrie FAS8000.

Igual que amb la NVRAM8 NetApp en els sistemes anteriors FAS, cada PCM FAS8020 inclou 4 GB de NVRAM9 (8GB per HA parell) amb bateria de suport; es produeix un tall d'energia, el contingut de la NVRAM es desconnectada per etapes en la memòria NAND flash. Un cop es restableixi l'energia, la NVLOG resultant es torna a jugar després de restaurar el sistema. NVRAM9 està integrada a la placa base i no ocupa una ranura.

El FAS8020 es basa en l'arquitectura de Gen 3 PCI Express (PCIe) per a dispositius encastats (com ponts PCI, Ethernet / Fibra adaptadors Canal / InfiniBand i controladors SAS). Els seus ranures admeten amplis vincles fins carrils x8.

Curiosament, la interconnexió de HA pel FAS8020 ara aprofita adaptadors 40Gb QDR InfiniBand; es tracta d'una millora substancial de la 10GBASE-KR (coure) o 10GBASE-SR tecnologia (fibra) que es troben dins de la FAS/V3220.

Una altra de les novetats per al FAS8020 és el nou adaptador Target Unificat (UTA) 2; una indústria d'emmagatzematge de NetApp primer. És compatible amb 16 GB de canal de fibra (FC) o 10Gb Ethernet, proporcionant flexibilitat en el futur. Tots dos ports s'han d'establir en la mateixa "personalitat" i el canvi d'un port UTA canviaran el segon port de la mateixa personalitat. El FAS8020 té un sol ASIC per als ports UTA2 a bord, i la tolerància a falles en els ASICs demana que la X1143A-R6.

La personalitat FC en l'UTA2 es Autorange velocitats d'enllaç de 16/8/4 Gb FC, però no treballar en 2 o 1 Gbps. El 10GbE no Autorange continuació velocitats de 10 GbE. És important tenir en compte que els ports UTA2 no són compatibles amb més vells prestatges FC DS14 o dispositius de cinta FC. Per a connectar amb prestatges DS14 o cinta FC, ús X1132A-R6 o X2054A-R6.

El FAS8020 pot contenir un màxim de 480 unitats o 240 unitats SSD (sistemàticament HA), amb una capacitat màxima de 1.920 TB. La quantitat màxima de Flash Cache i Flash Capacitat de la piscina (combinat) és de fins a 6 TB per part HA. La mida màxima d'agregat en un FAS8020 és 150TB i la mida màxima de volum és 70 TB.

Límits de node de Data ONTAP en clúster d'un FAS8020 són 24 per NAS i SAN per a 8 amb un grup homogeni. No és sorprenent que les regles de la plataforma de barreja amb clústers heterogenis (mixtes) limiten el FAS8020 amb FAS/V3220s, 3250s, 3270, 6210s i fins a un màxim de 8 nodes, tant per a SAN i NAS raïms. Els sistemes més moderns (com els FAS/V6220s, 6240/50s i 6280/90s) es qualifiquen amb 24 nodes per NAS i 8 nodes per a SAN amb el FAS8020 - igual que les agrupacions homogènies. També tingui en compte que el FAS8020 s'executa dins d'un (mixt) grup heterogeni de FAS/V3210s, FAS/V3240s o sistemes FAS22xx només s'ha classificat per a 4 nodes per a SAN i 4 nodes per NAS en aquest moment.


FAS8040/60
El factor de forma FAS8040 i FAS8060 (amb nom en codi: "Bimota") 6U estan dirigits a mitjanes i grans clients empresarials amb aplicacions crítiques de negoci i infraestructura de núvol.

Cada mòdul del processador de control FAS8040 (PCM) inclou un únic socket, 2.1 GHz Intel E5-2658 de processador "Sandy Bridge-EP" amb 8 nuclis (16 per part HA), un processador Intel Patsburg-J Southbridge, i 32 GB de memòria DDR3 física (64 GB per HA parell).

Cada PCM FAS8060 inclou dual-socket, 2.1 GHz Intel E5-2658 processadors "Sandy Bridge-EP" amb un total de 16 nuclis (32 per part HA), un processador Intel Patsburg-J Southbridge, i 64 GB de memòria DDR3 física (128 GB per HA parell). Utilització de la CPU de Data ONTAP en cada PCM FAS8060 arriba 1.560%; això vol dir que tots els 16 nuclis estan donant servei de manera activa la càrrega de treball (100% és igual a un nucli).

NetApp suporta configuracions de controlador únic i dual en un sol xassís, però a diferència dels sistemes anteriors, mòdul d'expansió d'E / S (IOXM) configuracions no són compatibles. L'augment de la barreja d'alt rendiment ports a bord i la flexibilitat que donen els nous ports UTA2 redueix la necessitat dels recomptes de tragamonedas més altes en la sèrie FAS8000.

Igual que amb la NVRAM8 NetApp en els sistemes anteriors FAS, cada FAS8040 o FAS8060 PCM inclou 8 GB de NVRAM9 (16GB per part HA) amb bateria de suport; es produeix un tall d'energia, el contingut de la NVRAM es desconnectada per etapes en la memòria NAND flash. Un cop es restableixi l'energia, la NVLOG resultant es torna a jugar després de restaurar el sistema. NVRAM9 està integrada a la placa base i no ocupa una ranura.

El FAS8040/60 es basa en l'arquitectura de Gen 3 PCI Express (PCIe) per a dispositius encastats (com ponts PCI, Ethernet / Fibra adaptadors Canal / InfiniBand i controladors SAS). Totes les ranures admeten enllaços d'ample x8.

Curiosament, la interconnexió de HA pel FAS8040/60 ara aprofita adaptadors 40Gb QDR InfiniBand; es tracta d'una millora substancial de la 10GBASE-KR (coure) o 10GBASE-SR tecnologia (fibra) que es troben dins de la FAS/V3250 i una modesta millora de la FAS/V6220 's InfiniBand 20Gb DDR interconnexió.

D'acord amb NetApp, el FAS8040 i FAS8060 han d'utilitzar els quatre ports de bord per a la interconnexió del clúster per assolir el màxim rendiment per a càrregues de treball a distància dins de Data ONTAP 8.2.1. Aquesta bona pràctica també garanteix implementacions poden prendre avantatge dels possibles augments de rendiment en futures versions de Data ONTAP.

Una altra de les novetats per al FAS8040 i FAS8060 és el nou adaptador Target Unificat (UTA) 2; una indústria d'emmagatzematge de NetApp primer. És compatible amb 16 GB de canal de fibra (FC) o 10Gb Ethernet, proporcionant flexibilitat en el futur. Tots dos ports s'han d'establir en la mateixa "personalitat" i el canvi d'un port UTA canviaran el segon port de la mateixa personalitat. El FAS8040 i FAS8060 tenen dos ASICs UTA2, i parells de ports són e0e/0e i e0f/0f compartir un ASIC, mentre que els parells de ports e0g/0g i e0h/0h comparteixen el segon ASIC.

La personalitat FC en l'UTA2 es Autorange velocitats d'enllaç de 16/8/4 Gb FC, però no treballar en 2 o 1 Gbps. El 10GbE no Autorange continuació velocitats de 10 GbE. És important tenir en compte que els ports UTA2 no són compatibles amb més vells prestatges FC DS14 o dispositius de cinta FC. Per a connectar amb prestatges DS14 o cinta FC, ús X1132A-R6 o X2054A-R6.

El FAS8040 pot contenir un màxim de 720 unitats o 240 unitats SSD (sistemàticament HA), amb una capacitat màxima de 2.880 TB. La quantitat màxima de Flash Cache i Flash Capacitat de la piscina (combinat) és de fins a 12 TB per part HA. La mida màxima d'agregat en un FAS8040 és 180 TB i la mida màxima de volum és de 100 TB.

El FAS8060 pot contenir un màxim de 1200 unitats o 240 unitats SSD (sistemàticament HA), amb una capacitat màxima de 4.800 TB. La quantitat màxima de Flash Cache i Flash Capacitat de la piscina (combinat) és de fins a 18 TB per part HA. La mida màxima d'agregat en un FAS8060 és 324TB i la mida màxima de volum és de 100 TB.

Límits de node de Data ONTAP en clúster d'un FAS8040/60 són 24 per NAS i SAN per a 8 amb un grup homogeni. No és sorprenent que les regles de la plataforma de barreja amb clústers heterogenis (mixtes) limiten el FAS8040/60 amb FAS/V3220s, 3250s, 3270, 6210s i fins a un màxim de 8 nodes, tant per a SAN i NAS raïms. Els sistemes més moderns (com els FAS/V6220s, 6240/50s i 6280/90s) es qualifiquen amb 24 nodes per NAS i 8 nodes per a SAN amb el FAS8040/60 - igual que les agrupacions homogènies.


RESUM
El FAS8000 està disponible per a la cita i l'ordre immediatament amb Data ONTAP 8.2.1 RC2. Es preveu que els enviaments començaran març de 2014. A partir de maig de 2014, els sistemes FAS8000 seran ordenables segons el configurat Clústers Fàbrica (FCC) francesos.
Tags: Categories: Geek ONTAP , generals Etiquetes:

Super Storage: L'opinió d'un Fan d'emmagatzematge de dades de la NFL

Com la majoria dels nord-americans, fa poc vaig veure l'esdeveniment més gran, més audaç i més fred en el futbol americà: el Super Bowl XLVIII amb 112.200.000 dels meus "amics" més propers.

Però encara que no va rebre emocionat pel gran joc, vostè encara podria estar interessat en aprendre sobre el paper d'emmagatzematge de dades per al programa de televisió més vist en la història dels Estats Units.

Durant la setmana prèvia al Super Bowl, vaig tenir el privilegi d'ajudar a sonar la campana d'obertura al NASDAQ MarketSite a la ciutat de Nova York - i el que una experiència ! També vaig tenir l'oportunitat de xerrar amb el director de la NFL de Tecnologia de la Informació, Aaron Amendolia, per explorar com aprofitar els sistemes d'emmagatzematge de NetApp per a la gestió de dades.

S'inicia amb 40 sistemes d'emmagatzematge NetApp FAS2200 Sèrie que emmagatzemen, protegeixen i serveixen a les dades dels 32 equips de la NFL, milers d'efectius, i milions de fans. Per exemple:

Vols estadístiques dels jugadors durant el joc? Tot joc jugar dades en brut és immediatament disponible i servida per sistemes d'emmagatzematge de NetApp.

? Com aquestes preses d'acció de televisió i diaris fotògrafs prendre centenars de milers de fotos i càmeres capturar vídeo d'alta definició de jocs de temporada regular, els playoffs i el Super Bowl - tots els emmagatzemats en els sistemes d'emmagatzematge de NetApp.

Veure algú que porta una placa? NetApp proporciona la infraestructura que suporta credencials de seguretat per a tots, des dels venedors de gossos calents al comissionat de la NFL.

També vaig aprendre que la NFL aprofita tota la pila de protocols (tant SAN i NAS), amb més del 90% de la seva infraestructura de màquines virtuals en execució en sistemes d'emmagatzematge de NetApp.

No obstant això, cada Super Bowl és únic.

Els usuaris finals de la NFL sovint es troben en els hotels amb connexions d'alta latència; maquinari es sotmet a ambients hostils en general no es troben dins de la majoria dels centres de dades (llauna de refresc vessaments, brutícia, sorra, etc.) La bona notícia és que SnapMirror, el programari de replicació integrada a Data ONTAP, permet a la NFL per a la commutació per error en el cas d'un problema.

De fet, posen a prova periòdicament els seus plans de recuperació de desastres amb la commutació per error (en viu) i la commutació per recuperació.

És clar, el seu equip favorit pot no haver arribat a la Super Bowl d'aquest any, però l'associació amb la NFL i els seus 32 equips no acaba amb el Super Bowl. És encara business-as-usual per a la infraestructura de TI de la NFL: l'actualització de llibres de jugades, streaming de vídeo, etc

Tot això requereix una plataforma d'emmagatzematge súper com NetApp: el proveïdor oficial d'emmagatzematge de dades de la NFL.
Tags: Categories: Geek ONTAP , generals Etiquetes:

NetApp Comunicats de Flash Accel 1.3.0

NetApp ha anunciat avui la disponibilitat de flash Accel 1.3.0, el seu programari de servidor que converteix el flaix de servidor compatible en un cau per als sistemes d'emmagatzematge de Data ONTAP de back-end.

La coherència, la persistència
Com en els alliberaments anteriors de Flash Accel 1.3.0 detecta i corregeix la coherència a nivell de bloc - en lloc de rentar tota la memòria cau. Esbandida tota la memòria cau pot ser bo ja que no hi ha problemes de coherència de dades, però terrible per al rendiment. Flash Accel memòria cau invalidació corregeix memòria cau, mentre es manté la memòria cau persistent.

A més de la coherència de dades intel · ligent, Flash Accel també proporciona la persistència en els reinicis VM / servidor.

El benefici tant de coherència de dades intel · ligent i persistència és assegurar que tant la memòria cau optimitza el rendiment en el seu millor moment (és a dir, quan la memòria cau està calenta) i que el rendiment màxim pot durar el major temps possible (en mantenir la memòria cau calent durant el major temps possible ).


Nota al marge: Codi de Flash Accel gestiona memòria cau del servidor, el que accelera l'accés a les dades emmagatzemades i gestionats per Data ONTAP en el sistema d'emmagatzematge. Flash Accel NO és codi Data ONTAP.

Què hi ha de nou
Flash Accel 1.3.0 afegeix les següents característiques i funcionalitats:

  • Compatibilitat amb Windows Server d'emmagatzematge en memòria cau de metall nu:
    • Windows 2008 R2, Windows 2012 i Windows 2012 R2
    • Suport FC i iSCSI de metall nu
    • Aplicacions en clúster suportats (memòria cau freda a la commutació per error)
  • Afegeix suport per a Windows 2012 i 2012 R2 màquines virtuals vSphere 5.5 i suport
    • Nota: per a l'ús de Flash amb Flash Accel Accel Management Console (FAMC), vSphere s'afegirà 5,5 suport a poques setmanes de la disponibilitat general de flash Accel 1.3
  • Fins a 4 TB de memòria cau per servidor
  • Suport per PCI-i STEC Accelerador
    • Nota: per a entorns VMware, Flash Accel 1.3.0 és inicialment només està disponible per al seu ús amb FAMC. 1.3.0 support for use with NetApp Virtual Storage Console (VSC) will be available when VSC 5.0 releases

Check the NetApp Interoperability Matrix Tool (IMT) under the new “Flash Accel” storage solution within the “Server Caching Solutions” category for the most up to date supported configurations.

Com a part d'aquest llançament, el consum de memòria s'ha reduït. Anteriorment, Flash Accel requereix 0.006 GB de memòria física al host per cada gigabyte de memòria del dispositiu i 0.006 GB de memòria addicional en la màquina virtual per a cada gigabyte d'espai de memòria cau assignat. Amb la versió 1.3.0, ara és possible configurar 0,0035 GB de memòria física (al host) i 0,0035 GB de memòria addicional (a la màquina virtual).

També és important tenir en compte que la mida de bloc de memòria cau per defecte en la versió 1.3.0 s'ha augmentat de 4 KB a 8 KB.

Flash Accel 1.3.0 es pot descarregar per qualsevol client de NetApp FAS i V-Sèries, sense cap cost. Per descarregar Flash Accel, visiteu el lloc de suport de NetApp .
Tags: Categories: Geek ONTAP , generals Etiquetes:

Snap Creador Deep Dive

NetApp Snap Marc Creator és un programari de protecció de dades que integra característiques de NetApp amb les aplicacions de tercers, bases de dades, hipervisor i sistemes operatius.

Snap Creador va ser desenvolupat originalment a l'octubre de 2007 per NetApp Professional Serveis Enginyeria de Resposta Ràpida per reduir (o fins i tot eliminar) scripting. Avui en dia, Snap Creator és una distribució de programari totalment compatibles disponibles al lloc de suport de NetApp.

L'Equip Creador Snap ofereix dues versions de Snap Creador: una versió de la comunitat i una versió oficial de NetApp. La versió de la comunitat inclou els últims complements, millores i característiques, però no suporta NetApp Suport. La versió NetApp està totalment provat i suportat, però no inclou els darrers plug-ins, característiques i millores.

Anem a explorar l'arquitectura de la recentment publicada Snap Creador 4.1 Comunitat de llançament al novembre de 2013.

Arquitectura Snap Creador Servidor
El Snap Server Creador s'instal normalment en un servidor centralitzat. Inclou un motor de flux de treball, que és un component XML impulsat per múltiples subprocessos que executa tots els comandaments de Snap Creador.

Tant el Creador GUI i CLI Snap, així com solucions de tercers (com ara cmdlets de PowerShell), aprofiten l'API Snap Creador. Per exemple, NetApp Workflow Automation pot aprofitar PowerShell cmdlets de comunicar a Snap Creador.

Per guardar les seves configuracions, Snap Creator inclou arxius de configuració i els perfils en el seu repositori; això inclou configuracions globals i configuracions globals a nivell de perfil. Si vostè està familiaritzat amb les versions anteriors de Snap Creador Server, un dels nous components és el repositori estès. Aquesta extensió proporciona una ubicació de base de dades per a cada treball, la informació importada sobre llocs de treball, i fins i tot les metadades plug-in.


Per la persistència, la base de dades Snap Creador emmagatzema detalls sobre els horaris Snap Creator i llocs de treball, així com els usuaris i els rols de RBAC.

La interfície d'emmagatzematge és un component del costat del servidor que s'encarrega de la comunicació a través de les API de Data ONTAP per executar les operacions del sistema d'emmagatzematge, com ara SnapVault, SnapMirror, etc Snap Creator també inclou la interfície Unified Manager que es comunica a OnCommand de NetApp Unified Manager; realment utilitza les API de Unified Manager (en lloc de les API ONTAP).

Finalment, el Creador Snap Server inclou una interfície d'agent que es comunica amb l'agent (que s'instal · la generalment en servidors externs al servidor Snap Creador). Anem a passar a l'Agent Creador Snap.

Arquitectura Agent Snap Creador
L'Agent Creador Snap 4.1 va ser reescrit recentment completament en Java per a ser multi-fil en tots els sistemes operatius. Com a part d'aquesta nova versió, el xifrat es va habilitar a tot el programari. Això significa que les versions anteriors (fins i incloent la versió 4.0) es comunicaran únicament a través d'HTTP; mentre que amb la versió 4.1, la comunicació es produeix només durant (xifrat) HTTPS.

En primer lloc, la interfície de l'agent (al servidor) parla amb RESTful interfície de l'agent. El component principal de l'Agent és el Gerent d'Operacions / Execució. És responsable de gestionar les peticions entrants, sortints i / o acabat mentre que el gerent d'Execució realitat completa aquestes peticions.

Per executar múltiples tasques, cada agent Creador Snap inclou un grup de subprocessos; consta de subprocessos de treball, que determinen el nombre d'operacions donades.

Però, què passa si una operació ha superat un valor de temps d'espera després d'un temps determinat? Això és quan Watchdog l'agent pot ser activat per l'administrador d'Execució. S'invoca sovint durant la manera inactiu operacions.


Moving on, there's a Context Store which holds information that is needed over the lifetime of the workflow.

The Snap Creator Agent also includes a Plug-in Factory that instantiates the plug-ins and communicates directly to the Context Store.

For Java Plug-ins, it's also important to note that it can directly talk back to the Context Store on the Agent, as well as to the Snap Creator Server -- via token-based storage access. This means that they can execute storage operations without communicating back to the Snap Creator Server. While this is a feature that hasn't been leveraged to date, it is nevertheless available moving forward.

But what happens if the Plug-in Factory instantiates a non-Java plug-in?

In this scenario, it executes the code of the existing Plug-in Integration Engine, which can run the version 4.0 or 3.6 plug-ins as well as supporting custom plug-ins written in Perl, Unix shell scripting, PowerShell, etc.

Resum
To recap, we've discussed both the server and agent architecture of Snap Creator 4.1. To learn more about developing plug-ins, visit SnapCreator.com .
Categories: Geek ONTAP , General Tags:

© 2009-2014 Chris Kranz Tots els drets reservats
Aquest lloc no té relació o patrocini de cap manera per NetApp o de qualsevol altra empresa esmentada en el seu interior.