none
Windows 2016: Problemi di performance Ethernet RRS feed

  • Domanda

  • Ciao a tutti,

    ho 2 macchine fisiche 2016 con configurazioni hardware pazzesche, su cui gira SQL 2016 in mirroring (....)

    Il witness server è stato fatto con una VMware posta sul "nodo" 2.

    La configurazione desiderata prevede: 2 gigabit extreme in teaming per il failover (tipo staccano il cavo..)

    1 gb extreme per avere routing corretto dal nodo 2 alla virtuale (misteri di VMWare workstation..senza la eth fisica dal nodo 2 non raggiungo il witness e viceversa)

    Ora le domande:

    1) la priorità delle schede di rete su 2016 si basa solo sulla metrica assegnata alle interfacce?

    2) Come faccio a far passare effettivamente il traffico di rete solo sulla scheda in teaming? ho visto che lanciando un copy file, lo stesso passa sulla eth witness e non voglio faccia questo.

    3) C'è qualche settings specifico per gli SSD su 2016?

    Si accettano consigli.

    Un caro saluto

    mercoledì 28 febbraio 2018 08:47

Risposte

  • Eccomi qua! Anzitutto ho finalmente risolto l'inghippo che strozzava il trasferimento dati lato rete, in maniera barbara - non professionale - istintiva - ma evidentemente (che culo) efficace: ho semplicemente distrutto la scheda ethernet BRIDGE virtuale che era stata messa in piedi sfruttando 2 ethernet fisiche... dopo che ho scoperto che sullo switch non c'era trunk e i 2 cavi erano fisicamente attaccati allo stesso switch, avevo messo in disable una ethernet fisica ma evidentemente qualcosa non gli piaceva.

    Ora ho IP statico su singola ethernet e stop. Il transfer è finalmente funzionante.

    Tornando alle tue sacrosante domande:

    1) Se il "nodo" 2 + virtuale vanno in down, nessun problema. I db rimangono sul nodo 1.

    2) Se il nodo 1 va giù, i db switchano sul nodo 2

    3) In test che ho fatto su ambiente virtuale, ho visto che ci sono delle situazioni in cui devi necessariamente restartare per es. il witness sul nodo 1 e/o in cui sei costretto a disfare il mirroring o devi lanciare i comandi SQL per il DR.

    4) hai ragione sul discorso witness, ma ti dirò di più: il mirroring, come sappiamo, è deprecato. Avrei fatto con 3 macchine o 2 + 1 share di rete la replica o un cluster..

    Grazie per il support!!!

    giovedì 1 marzo 2018 11:36

Tutte le risposte

  • Ciao. non ho capito. Tu hai 2 server fisici con su 2016 e poi parli di Vmware come witness sul nodo 2...o è tutto virtuale o è tutto fisico oppure il testimone se ne sta fuori dalle 2 macchine fisiche altrimenti vedo già una serie di problematiche legate al networking..

    boh..spiega un po meglio.

    A.

    mercoledì 28 febbraio 2018 17:03
    Moderatore
  • 2 Macchine fisiche; su una delle 2 ho VMware Workstation con un 3° server win 2016 + SQL 2016 per la gestione del witness/mirroring.

    Perchè tutto fisico o tutto virtuale?

    Premesso che si sarebbe potuto sfruttare Hyper-V e sarebbe stata opportuna un'altra architettura per SQL...

    giovedì 1 marzo 2018 08:18
  • Francesco, Vmware Workstation non è mica per la produzione, è solo per ambiente di test, sei in una configurazione totalmente unsupported, ci credo che hai problemi di rete. Così non funzionerà mai. Se vuoi avere un barlume di funzionamento o fai tutto virtuale con hypervisor esx o vmware oppure il testimone lo tiri fuori di li e fai una terza macchina fisica o una macchina con hypervisor e ci piazzi su un testimone, ma non deve stare su una della due...cioè siamo chiari, chi ha fatto la struttura avrà messo HW da paura ma non ha fatto un minimo di survey tecnica per sapere come funziona il tutto prima di metterlo su...

    A.

    giovedì 1 marzo 2018 08:26
    Moderatore
  • Alessandro, you're right, cosi è e cerco di farlo funzionare nel migliore dei modi..

    TRa l'altro nessuno si è mai accorto del problema nei transfer file; dopotutto la parte sql gira bene, i RDS anche (c'è anche quello), il ping interno è ottimo. Peccato appunto che se devi fare un backup e/o spostare files fa veramente schifo a livelli inverosimili.

    giovedì 1 marzo 2018 09:37
  • Francesco..nun me stai a sentì :-) ..è unsupported. Vuol dire che ogni problema che hai poi se ti cade uno dei nodi ed il testimone non switcha ti va fuori coerenza il database e non lo riprendi più ed il supporto MS non ti ci mette nemmeno le mani..oltre questo il primo Sysadmin esterno che viene interpellato ti mette alla pubblica gogna.. Se l'hai fatto tu o no non è un mio problema, ma visto che ora sei a conoscenza della problematica ignorarlo è poco etico verso il cliente.

    Qui non stiamo parlando di problemi di networking e transfer rate, stiamo parlando di una struttura che dovrebbe essere fault tolerance e non lo è che è diverso. Se ti schianta il nodo fisico dove c'è su il testimone virtualizzato? hai provato a fare un test e vedere cosa succede?

    Se vuoi puoi: 

    - installare un hypervisor ESX Vmware esterno

    - Migrare la VM Witness da Workstation a Vsphere

    - backuppare la VM testimone con un SW per le Vm

    poi ti occupi dei problemi del transfer..che sono dati comunque da che giro fanno i pacchetti perchè quello con su Workstation ha una gestione diversa dall'altro considerato che avrà due schede virtuali in più ed una che condivide in bridge per il testimone...

    Ciao!

    A.

    giovedì 1 marzo 2018 09:51
    Moderatore
  • Alessandro, lungi da me il non volerti ascoltare, anzi. Ringrazio sempre chi ne sa di più e/o più erudito del sottoscritto;)

    Detto questo, non sempre le situazioni in essere possono/vogliono essere modificate e non sempre puoi quindi fare il meglio. Questo purtroppo lo vivo sulla mia pelle, ma dubito sia il solo, qui in Italia......

    Detto ciò: se si schianta il "nodo 2", c'è la vm replicata sul nodo 1..

    (immagino il tuo commento .. :D )

    giovedì 1 marzo 2018 10:01
  • :-) quindi è stata fatta la prova? del tipo stacco qua, stacco là, stacco a caso? perchè sulle strutture replicate si fa così...secondo me se il master in quel momento (perchè c'è sempre un master anche se è un millisecondo) è il nodo dove c'è su la VM e si schianta tutto in una volta il testimone non passa l'informazione e tu rimani a piedi con tutto ed hai il DB fuori coerenza...quindi ti trovi poi 2 db replicati non accessibili (l'ho visto succedere, non lo dico per spaventarti sia chiaro).

    ad ogni modo così non riesco a darti consigli ulteriori su come far funzionare il tutto correttamente perchè hai una struttura falsata quindi qualsiasi cosa ti dica nel tuo caso è inapplicabile purtroppo...

    PS una macchinetta del piffero per metterci su un ESX e fargli da testimone esterno costa si e no 1.000€ per una singola VM...non so se decade tutto quanto costi poi...io ci penserei...

    :-(

    ciao!

    A.

    giovedì 1 marzo 2018 11:19
    Moderatore
  • Eccomi qua! Anzitutto ho finalmente risolto l'inghippo che strozzava il trasferimento dati lato rete, in maniera barbara - non professionale - istintiva - ma evidentemente (che culo) efficace: ho semplicemente distrutto la scheda ethernet BRIDGE virtuale che era stata messa in piedi sfruttando 2 ethernet fisiche... dopo che ho scoperto che sullo switch non c'era trunk e i 2 cavi erano fisicamente attaccati allo stesso switch, avevo messo in disable una ethernet fisica ma evidentemente qualcosa non gli piaceva.

    Ora ho IP statico su singola ethernet e stop. Il transfer è finalmente funzionante.

    Tornando alle tue sacrosante domande:

    1) Se il "nodo" 2 + virtuale vanno in down, nessun problema. I db rimangono sul nodo 1.

    2) Se il nodo 1 va giù, i db switchano sul nodo 2

    3) In test che ho fatto su ambiente virtuale, ho visto che ci sono delle situazioni in cui devi necessariamente restartare per es. il witness sul nodo 1 e/o in cui sei costretto a disfare il mirroring o devi lanciare i comandi SQL per il DR.

    4) hai ragione sul discorso witness, ma ti dirò di più: il mirroring, come sappiamo, è deprecato. Avrei fatto con 3 macchine o 2 + 1 share di rete la replica o un cluster..

    Grazie per il support!!!

    giovedì 1 marzo 2018 11:36

  • Grazie per il support!!!

    no problema...magari la prossima volta porterai qualcosa di support e non usupport :-) noi siamo qui.

    ciao.

    A.

    giovedì 1 marzo 2018 12:52
    Moderatore