Neste artigo, gustaríame falar sobre as funcións das matrices All Flash AccelStor que traballan cunha das plataformas de virtualización máis populares: VMware vSphere. En particular, céntrase neses parámetros que che axudarán a obter o máximo efecto de usar unha ferramenta tan poderosa como All Flash.
AccelStor NeoSapphire™ Todas as matrices Flash son ou dispositivos de nodos baseados en unidades SSD cun enfoque fundamentalmente diferente para implementar o concepto de almacenamento de datos e organizar o acceso a el mediante tecnoloxía propietaria en lugar dos moi populares algoritmos RAID. As matrices proporcionan acceso en bloque aos hosts a través de interfaces Fibre Channel ou iSCSI. Para ser xustos, observamos que os modelos cunha interface ISCSI tamén teñen acceso a ficheiros como unha boa vantaxe. Pero neste artigo centrarémonos no uso de protocolos de bloque como os máis produtivos para All Flash.
Todo o proceso de implantación e posterior configuración da operación conxunta da matriz AccelStor e do sistema de virtualización VMware vSphere pódese dividir en varias etapas:
- Implantación da topoloxía de conexión e configuración da rede SAN;
- Configuración da matriz All Flash;
- Configurando hosts ESXi;
- Configurar máquinas virtuais.
Utilizáronse matrices de canle de fibra AccelStor NeoSapphire™ e matrices iSCSI como hardware de mostra. O software base é VMware vSphere 6.7U1.
Antes de implantar os sistemas descritos neste artigo, recoméndase encarecidamente que lea a documentación de VMware sobre problemas de rendemento ( ) e configuración iSCSI ()
Topoloxía de conexión e configuración da rede SAN
Os compoñentes principais dunha rede SAN son os HBA en hosts ESXi, conmutadores SAN e nodos de matriz. Unha topoloxía típica para unha rede deste tipo sería así:
O termo Switch aquí fai referencia tanto a un conmutador físico ou conxunto de conmutadores (Fabric) como a un dispositivo compartido entre diferentes servizos (VSAN no caso de Fibre Channel e VLAN no caso de iSCSI). O uso de dous interruptores/tecidos independentes eliminará un posible punto de falla.
A conexión directa dos anfitrións á matriz, aínda que é compatible, non é moi recomendable. O rendemento das matrices All Flash é bastante alto. E para a velocidade máxima, deben usarse todos os portos da matriz. Polo tanto, é obrigatoria a presenza de polo menos un cambio entre os hosts e NeoSapphire™.
A presenza de dous portos no HBA host tamén é un requisito obrigatorio para acadar o máximo rendemento e garantir a tolerancia a fallos.
Cando se utiliza unha interface Fibre Channel, debe configurarse a zonificación para eliminar posibles colisións entre iniciadores e obxectivos. As zonas están construídas no principio de "un porto iniciador: un ou máis portos de matriz".
Se usa unha conexión a través de iSCSI no caso de utilizar un conmutador compartido con outros servizos, é imprescindible illar o tráfico iSCSI nunha VLAN separada. Tamén é moi recomendable habilitar a compatibilidade con tramas Jumbo (MTU = 9000) para aumentar o tamaño dos paquetes na rede e, así, reducir a cantidade de información de sobrecarga durante a transmisión. Non obstante, convén lembrar que para un funcionamento correcto é necesario cambiar o parámetro MTU en todos os compoñentes da rede ao longo da cadea "iniciador-switch-target".
Configuración da matriz All Flash
A matriz entrégase aos clientes con grupos xa formados . Polo tanto, non é necesario tomar accións para combinar unidades nunha única estrutura. Só precisa crear volumes do tamaño e cantidade necesarios.
Para comodidade, hai unha funcionalidade para a creación de lotes de varios volumes dun determinado tamaño á vez. De forma predeterminada, créanse volumes finos, xa que isto permite un uso máis eficiente do espazo de almacenamento dispoñible (incluído o soporte para a recuperación de espazo). En canto ao rendemento, a diferenza entre volumes "finos" e "grosos" non supera o 1%. Non obstante, se queres "exprimir todo o zume" dunha matriz, sempre podes converter calquera volume "delgado" nun "groso". Pero hai que lembrar que tal operación é irreversible.
A continuación, queda por "publicar" os volumes creados e establecer dereitos de acceso a eles desde os hosts mediante ACL (enderezos IP para iSCSI e WWPN para FC) e separación física por portos de matriz. Para os modelos iSCSI, isto faise creando un destino.
Para os modelos FC, a publicación prodúcese mediante a creación dun LUN para cada porto da matriz.
Para acelerar o proceso de configuración, os hosts pódense combinar en grupos. Ademais, se o host usa un FC HBA multiporto (o que na práctica ocorre con máis frecuencia), entón o sistema determina automaticamente que os portos deste tipo de HBA pertencen a un único host grazas a WWPN que difieren nun. A creación por lotes de Target/LUN tamén é compatible con ambas as interfaces.
Unha nota importante cando se usa a interface iSCSI é crear varios obxectivos para volumes á vez para aumentar o rendemento, xa que a cola do destino non se pode cambiar e será efectivamente un pescozo de botella.
Configuración de hosts ESXi
No host ESXi, a configuración básica realízase segundo un escenario completamente esperado. Procedemento para a conexión iSCSI:
- Engadir adaptador iSCSI de software (non é necesario se xa se engadiu ou se está a usar o adaptador iSCSI de hardware);
- Crear un vSwitch polo que pasará o tráfico iSCSI e engadirlle unha ligazón ascendente física e VMkernal;
- Engadir enderezos de matriz a Dynamic Discovery;
- Creación de almacén de datos
Algunhas notas importantes:
- No caso xeral, por suposto, pode usar un vSwitch existente, pero no caso dun vSwitch separado, xestionar a configuración do host será moito máis sinxelo.
- É necesario separar o tráfico de xestión e iSCSI en ligazóns físicas e/ou VLAN separadas para evitar problemas de rendemento.
- Os enderezos IP do VMkernal e os portos correspondentes da matriz All Flash deben estar dentro da mesma subrede, de novo debido a problemas de rendemento.
- Para garantir a tolerancia a fallos segundo as regras de VMware, vSwitch debe ter polo menos dúas ligazóns ascendentes físicas
- Se se usan marcos Jumbo, cómpre cambiar o MTU de vSwitch e VMkernal
- Sería útil lembrar que segundo as recomendacións de VMware para os adaptadores físicos que se utilizarán para traballar co tráfico iSCSI, é necesario configurar Teaming e Failover. En particular, cada VMkernal debe funcionar a través dun só enlace ascendente, o segundo enlace ascendente debe cambiarse ao modo non utilizado. Para a tolerancia a fallos, cómpre engadir dous VMkernals, cada un dos cales funcionará a través da súa propia ligazón ascendente.
Adaptador VMkernel (vmk#)
Adaptador de rede física (vmnic#)
vmk1 (almacenamento01)
Adaptadores activos
vmnic2
Adaptadores sen usar
vmnic3
vmk2 (almacenamento02)
Adaptadores activos
vmnic3
Adaptadores sen usar
vmnic2
Non se precisan pasos previos para conectarse mediante Fibre Channel. Podes crear inmediatamente un Datastore.
Despois de crear o almacén de datos, cómpre asegurarse de que a política de Round Robin para as rutas ao destino/LUN se utiliza como a máis eficaz.
Por defecto, a configuración de VMware prevé o uso desta política segundo o esquema: 1000 solicitudes a través do primeiro camiño, as seguintes 1000 solicitudes a través do segundo camiño, etc. Tal interacción entre o host e a matriz de dous controladores estará desequilibrada. Polo tanto, recomendamos configurar a política Round Robin = 1 parámetro a través de Esxcli/PowerCLI.
Parámetros
Para Esxcli:
- Lista dos LUN dispoñibles
Lista de dispositivos nmp de almacenamento esxcli
- Copiar o nome do dispositivo
- Cambiar a política de Round Robin
esxcli storage nmp psp roundrobin deviceconfig set —type=iops —iops=1 —device=“Device_ID”
A maioría das aplicacións modernas están deseñadas para intercambiar grandes paquetes de datos co fin de maximizar a utilización do ancho de banda e reducir a carga da CPU. Polo tanto, ESXi emite solicitudes de E/S de forma predeterminada ao dispositivo de almacenamento en anacos de ata 32767 KB. Non obstante, para algúns escenarios, o intercambio de anacos máis pequenos será máis produtivo. Para as matrices de AccelStor, estes son os seguintes escenarios:
- A máquina virtual usa UEFI en lugar de Legacy BIOS
- Usa vSphere Replication
Para tales escenarios, recoméndase cambiar o valor do parámetro Disk.DiskMaxIOSize a 4096.
Para conexións iSCSI, recoméndase cambiar o parámetro de tempo de espera de inicio de sesión a 30 (predeterminado 5) para aumentar a estabilidade da conexión e desactivar o atraso DelayedAck para confirmacións dos paquetes reenviados. Ambas opcións están en vSphere Client: Host → Configurar → Almacenamento → Adaptadores de almacenamento → Opcións avanzadas para o adaptador iSCSI
Un punto bastante sutil é o número de volumes utilizados para o almacén de datos. Está claro que para facilitar a xestión, existe o desexo de crear un gran volume para todo o volume da matriz. Non obstante, a presenza de varios volumes e, en consecuencia, o almacén de datos ten un efecto beneficioso sobre o rendemento xeral (máis información sobre as colas a continuación). Polo tanto, recomendamos crear polo menos dous volumes.
Ata hai relativamente pouco tempo, VMware aconsellaba limitar o número de máquinas virtuais nun almacén de datos, de novo para obter o maior rendemento posible. Non obstante, agora, especialmente coa propagación do VDI, este problema xa non é tan agudo. Pero isto non anula a regra de longa data: distribuír máquinas virtuais que requiren IO intensiva en diferentes almacéns de datos. Para determinar o número óptimo de máquinas virtuais por volume, non hai nada mellor que dentro da súa infraestrutura.
Configurar máquinas virtuais
Non hai requisitos especiais á hora de configurar máquinas virtuais, ou máis ben son bastante comúns:
- Usando a versión de VM máis alta posible (compatibilidade)
- É máis coidadoso establecer o tamaño da RAM cando se colocan densamente máquinas virtuais, por exemplo, en VDI (xa que por defecto, ao iniciarse, créase un ficheiro de páxina dun tamaño acorde coa RAM, que consume capacidade útil e afecta a a actuación final)
- Use as versións de adaptador máis produtivas en canto a IO: tipo de rede VMXNET 3 e tipo SCSI PVSCSI
- Use o tipo de disco Thick Provision Eager Zeroed para o máximo rendemento e Thin Provisioning para o máximo aproveitamento do espazo de almacenamento
- Se é posible, limite o funcionamento de máquinas críticas non E/S mediante Virtual Disk Limit
- Asegúrese de instalar VMware Tools
Notas sobre as filas
A cola (ou E/S pendentes) é o número de solicitudes de entrada/saída (comandos SCSI) que están á espera de ser procesadas nun momento dado para un dispositivo/aplicación específico. En caso de desbordamento da cola, emítense erros QFULL, o que finalmente resulta nun aumento do parámetro de latencia. Cando se usan sistemas de almacenamento en disco (spindle), en teoría, canto maior sexa a cola, maior será o seu rendemento. Non obstante, non debes abusar dela, xa que é fácil atopar QFULL. No caso dos sistemas All Flash, por unha banda, todo é algo máis sinxelo: ao cabo, a matriz ten latencias ordes de magnitude inferiores e, polo tanto, a maioría das veces non é necesario regular por separado o tamaño das filas. Pero, por outra banda, nalgúns escenarios de uso (forte sesgo nos requisitos de E/S para máquinas virtuais específicas, probas para o máximo rendemento, etc.) é necesario, se non cambiar os parámetros das filas, polo menos entender que indicadores pódese conseguir, e, o principal é de que maneiras.
Na propia matriz AccelStor All Flash non hai límites en relación aos volumes ou aos portos de E/S. Se é necesario, mesmo un só volume pode recibir todos os recursos da matriz. A única limitación da cola é para os obxectivos iSCSI. É por iso que anteriormente se indicou a necesidade de crear varios obxectivos (idealmente ata 8 pezas) para cada volume para superar este límite. Repetimos tamén que as matrices AccelStor son solucións moi produtivas. Polo tanto, debes usar todos os portos de interface do sistema para acadar a máxima velocidade.
No lado do host ESXi, a situación é completamente diferente. O propio anfitrión aplica a práctica de igual acceso aos recursos para todos os participantes. Polo tanto, hai colas de E/S separadas para o SO convidado e o HBA. As colas do sistema operativo convidado combínanse desde as colas ao adaptador SCSI virtual e ao disco virtual:
A cola para o HBA depende do tipo/fornecedor específico:
O rendemento final da máquina virtual estará determinado polo límite de profundidade de cola máis baixo entre os compoñentes do host.
Grazas a estes valores, podemos avaliar os indicadores de rendemento que podemos obter nunha determinada configuración. Por exemplo, queremos coñecer o rendemento teórico dunha máquina virtual (sen enlace de bloque) cunha latencia de 0.5 ms. Entón, o seu IOPS = (1,000/latencia) * E/S pendentes (límite de profundidade da cola)
Exemplos
Exemplo 1
- Adaptador FC Emulex HBA
- Unha máquina virtual por almacén de datos
- Adaptador SCSI paravirtual de VMware
Aquí o límite de profundidade da cola está determinado por Emulex HBA. Polo tanto, IOPS = (1000/0.5)*32 = 64K
Exemplo 2
- Adaptador de software VMware iSCSI
- Unha máquina virtual por almacén de datos
- Adaptador SCSI paravirtual de VMware
Aquí o límite de profundidade da cola xa está determinado polo adaptador SCSI Paravirtual. Polo tanto, IOPS = (1000/0.5)*64 = 128K
Modelos principais de matrices All Flash AccelStor (por exemplo, ) son capaces de ofrecer un rendemento de escritura de 700 4 IOPS por bloque en 11 K. Con tal tamaño de bloque, é bastante obvio que unha única máquina virtual non é capaz de cargar tal matriz. Para iso, necesitará 1 (por exemplo 6) ou 2 (por exemplo XNUMX) máquinas virtuais.
Como resultado, coa configuración correcta de todos os compoñentes descritos dun centro de datos virtual, pode obter resultados moi impresionantes en termos de rendemento.
4K aleatorio, 70 % de lectura/30 % de escritura
De feito, o mundo real é moito máis complexo do que se pode describir cunha fórmula sinxela. Un host sempre aloxa varias máquinas virtuais con diferentes configuracións e requisitos de E/S. E o procesamento de E/S é xestionado polo procesador host, cuxa potencia non é infinita. Así, para desbloquear todo o potencial do mesmo en realidade, necesitarás tres anfitrións. Ademais, as aplicacións que se executan dentro de máquinas virtuais fan os seus propios axustes. Polo tanto, ofrecemos un tamaño preciso Todas as matrices Flash dentro da infraestrutura do cliente sobre tarefas actuais reais.
Fonte: www.habr.com