Cookie necessari
Strumento gratuito di pianificazione di rete
Dimensiona per il traffico e per il guasto di un server.
Verifica il budget di rete del tuo cluster di filtraggio. Aggiungi le tue misurazioni per confrontare i limiti software e vedere cosa resta quando alcuni server non sono disponibili.
Funzionamento normale e perdita di server
Tutti i budget seguenti riservano già il margine selezionato. L’uscita filtrata è dimensionata per il caso conservativo in cui tutto il traffico in ingresso debba essere inoltrato.
Scorri orizzontalmente per vedere tutte le colonne.
| Scenario | Server disponibili | Budget di rete | Budget secondo le tue misurazioni | Valutazione |
|---|---|---|---|---|
| Tutti i server disponibili | 2 | 160 Gbps | Non indicato | Entro il budget indicatoCapacità software sconosciuta |
| Server indisponibili : 1 | 1 | 80 Gbps | Non indicato | Budget insufficienteCapacità software sconosciuta |
I valori visualizzati sono arrotondati; il calcolo conserva la precisione completa.
Il percorso dimensionato
- Ingresso non filtrato
- Server di filtraggio
- Uscita filtrata
Il modello usa porte di ingresso e uscita distinte, alla stessa velocità. Trunk condivisi, architetture a singolo collegamento, traffico inverso e collegamenti di bypass richiedono budget separati.
Un modello limitato, con ipotesi esplicite
- Due scenari di picco
- Il fabbisogno di rete è il maggiore tra il picco Gbps inserito e la velocità sul collegamento derivata dallo scenario PPS. Sono casi di pianificazione distinti, non una ricostruzione del traffico reale.
- Le porte si contano una sola volta lungo il percorso
- Con due porte dati 100G, una riceve e l’altra trasmette: il modello parte da un budget di 100G in una direzione. Quattro porte offrono due coppie, a condizione che la distribuzione del carico funzioni.
- Riserva il margine prima di contare i server
- Capacità utilizzabile = capacità × (1 − margine / 100). Dividi il carico richiesto per il budget utilizzabile di un server, arrotonda per eccesso e aggiungi il numero selezionato di server che possono andare persi.
- Usa entrambi i limiti misurati quando disponibili
- I Gbps misurati sono limitati al budget fisico delle porte in questo modello. Si mantiene il numero maggiore di server richiesto dai vincoli Gbps e Mpps. La velocità di una NIC non determina una prestazione software misurata.
Cosa deve ancora essere verificato prima del deployment
- Valida code NIC, capacità PCIe, collocazione NUMA, CPU e memoria con le regole di filtraggio e la combinazione reale di pacchetti.
- Prova la distribuzione nel funzionamento normale e dopo un guasto. Un budget aggregato non dimostra che un singolo flusso, un prefisso o una distribuzione hash sbilanciata vi rientrino.
- Verifica convergenza del routing, sessioni con stato, MTU e ritorno filtrato. I soli server di riserva non garantiscono il failover automatico.
- Rispetta anche i limiti dei collegamenti upstream. Il software locale non può recuperare traffico già perso su un accesso saturo.
- Qualifica throughput e guasti in un ambiente di test isolato e autorizzato prima di fare affidamento sul piano.
Domande
Due porte 100G contano come 200G di filtraggio?
No. Il modello associa una porta di ingresso non filtrato a una porta di uscita filtrata. La coppia offre un budget fisico di 100G in una direzione prima del margine, e il software può sostenere meno.
Il numero minimo di server certifica le prestazioni di Defense Fabric?
No. Senza misurazioni è solo un minimo di capacità di rete. Con le misurazioni, confronta i limiti dichiarati secondo le ipotesi indicate; non è un benchmark Peeryx né un collaudo del deployment.
Perché i PPS possono aumentare il fabbisogno di Gbps?
Il pianificatore converte lo scenario PPS usando la dimensione dei frame indicata, incluso il tempo occupato dall’overhead Ethernet. Mantiene il fabbisogno di rete maggiore tra questo scenario e il picco Gbps separato. Controlla dimensione dei frame e definizioni dei contatori se la differenza è notevole.
Il calcolatore configura la ridondanza?
No. Calcola la capacità con meno server disponibili. Il failover reale dipende da routing, rilevamento dei guasti, gestione dello stato, topologia fisica e una procedura di ripristino collaudata.
Riferimenti tecnici
Confronta il piano con il tuo deployment
Consulta la guida Defense Fabric per i requisiti d’integrazione oppure valuta un Transit protetto se la rete d’accesso è il fattore limitante.