Trantor® TVStor eroga lo storage a blocchi/file/oggetti di cui la tua azienda ha bisogno, e lo fa on-premise e senza vendor lock-in. E l’hardware puoi comprarlo da noi, o comprarlo tramite il tuo fornitore di fiducia, perché giriamo su server standard.
Perché Trantor® TVStor
Le SAN e NAS tradizionali seguono tutte lo stesso copione: coppia di controller proprietari, moduli di espansione dello stesso vendor, scalabilità e ridondanza limitate e poi alla fine, quando si vuole cambiare vendor, la migrazione mette in crisi tutta l’infrastruttura. TVStor cambia copione: una SAN/NAS fatta di software e server standard, scale-out invece di scale-up, fornita in bundle col nostro hardware, o installata sui server che compri dove vuoi o possiedi già. E non è uno storage qualunque: storage a blocchi iSCSI/NVMe, object storage S3, NAS completa con editing Office collaborativo dal browser, e il ruolo di HA-gateway per le SAN che già possiedi.
Un’altra forma di SAN/NAS
Un’appliance software su hardware standard: arriva chiavi in mano su hardware standard fornito da noi, oppure si installa sui server che già possiedi, e diventa una SAN operativa, gestita dalla sua console.
L’esperienza resta quella di una SAN: volumi, LUN e host si amministrano con il lessico e i protocolli che i tuoi sistemi già conoscono.
Due motori, una SAN: Ceph per lo scale-out senza limiti, o TVStor MultiSCSI, orchestrazione Trantor su formati aperti, per partire anche da due soli nodi.
Due motori, una scelta
Motore Ceph, da 3 nodi
Lo stesso motore che regge alcuni dei più grandi cluster storage del mondo: repliche sincrone o erasure coding, auto-riparazione, scrubbing continuo dell’integrità, ribilanciamento automatico e scale-out senza limiti pratici. La scelta naturale quando la crescita non ha un tetto.
Motore TVStor MultiSCSI, da 2 nodi
Orchestrazione di replica e alta disponibilità firmata Trantor, su formati aperti, MDADM, LVM e NVMe/TCP: i dischi restano leggibili anche fuori da TVStor. Stessa famiglia concettuale di LINSTOR + DRBD, su una base moderna e pulita. Parte da due nodi, con i limiti HA che due nodi comportano, dichiarati, e cresce nei cluster dispari standard.
Crescita lineare: capacità e prestazioni si aggiungono nodo per nodo e disco per disco, con riequilibrio online, senza fermi, senza sostituire ciò che c’è.
«La complessità del motore resta sotto il cofano, TVStor ti dà a disposizione un’interfaccia semplice e pulita.»
Panoramica delle funzionalità
Storage a blocchi, a oggetti e a file, tutto dalla stessa dashboard.
Storage a blocchi
iSCSI, NVMe/TCP, FC e FCoE con multipath (MPIO): ogni host si collega con il suo initiator nativo, su percorsi ridondati
Gestione da SAN: pool, volumi, LUN, mappature e masking per host, il modello mentale che già conosci
Thin provisioning: i volumi consumano solo lo spazio realmente scritto
Snapshot istantanee e space-efficient, manuali o pianificate, con retention
Cloni scrivibili da snapshot, per test, sviluppo e ripartenze
Espansione online e shrink, con conferma esplicita
QoS per volume: limiti di IOPS e banda per i vicini rumorosi
Compressione per pool sul motore Ceph e storage pool multipli sotto una console
Storage a oggetti
Endpoint S3 nativo: bucket applicativi accanto ai volumi, stessa macchina e stessa console
Object Lock per l’immutabilità lato destinazione, con account e chiavi nel keystore cifrato
La catena resta in casa: i backup immutabili di TVStor possono puntare all’object store di TVStor
API S3 standard: le applicazioni che parlano S3 non si accorgono della differenza
Storage a file
NFS v3 e v4 per il mondo Unix e la virtualizzazione
SMB per client Windows e macOS, con Active Directory / LDAP e Kerberos
SFTP in ambiente confinato, per scambi sicuri e automazioni
ACL ricche, NT, POSIX e NFSv4, mappate correttamente fra i mondi
Quote per share e per utente, dichiarate e applicate
Versioni precedenti (VSS) dalle snapshot: il ripristino se lo fa l’utente, dal suo Esplora risorse
Esplora file via web browser
Cartelle e navigazione stile Drive, dal browser, senza client da installare
Upload e download anche di cartelle intere, nelle due direzioni
Anteprime di documenti e immagini, prima di aprire
Editing Office collaborativo in tempo reale: più persone sullo stesso documento, dal browser
Gli stessi utenti e le stesse ACL della NAS: i permessi non si duplicano, si ereditano
Tutto resta on-premise: i file non lasciano mai la tua SAN
Servizi di rete
FTP e FTPS verso gli share, per i flussi legacy che non muoiono mai
Boot PXE con TFTP e DHCP integrato: la NAS che accende anche i tuoi server
IP di servizio che segue il failover: i client non si accorgono del nodo
Onestà di architettura: sulla coppia il servizio file è active/passive; lo scale-out file è il mestiere di CephFS
Panoramica tecnica
Architettura
Un cluster TVStor può essere formato da un minimo di 1 nodo a un massimo di 7 nodi (al suo interno, gli eventuali cluster Ceph/MultiSCSI creati hanno i loro limiti specifici: Ceph da 3 a 7 nodi, MultiSCSI da 1 a 4 nodi).
vDisk: gestione dischi locali
Le appliance TVStor possono usare i dischi locali in queste modalità: un disco locale viene diviso in più chunk di uguale dimensione (per esempio, un disco di 1024GiB può essere suddiviso in 16 chunk da 64GiB), dopodiché si possono opzionalmente creare volumi RAID 0/1/5/6/10 tra i chunk dei vari dischi (esempio: ho il disco1 con 10 chunk da 32GiB liberi e il disco2 con 12 chunk da 64GiB liberi, posso creare un volume RAID1 che usa 4 chunk del disco1 e 2 chunk del disco2 e in totale il volume RAID ha 128GiB usabili; un volume RAID viene sempre applicato ai chunk di dischi diversi). Una volta preparato l’ambiente fisico, si possono creare i vDisk, che sono l’unità sulla quale si costruiscono i cluster Ceph/MultiSCSI dentro TVStor. Un vDisk può usare o un intero volume RAID (creato prima) oppure può usare uno o più chunk di un singolo disco, che vengono aggregati (es. posso avere il vdisk1 che usa il raidvol1 e il vdisk2 che usa 4 chunk del disco1).
vDisk: gestione dischi remoti
Un vDisk, oltre a poter essere basato su volumi RAID e chunk locali, può anche puntare a una LUN esterna: a livello pratico, una LUN esposta da una SAN esterna (tramite iSCSI, NVMe/TCP, SCSI/FC, NVMe/FC, NVMe/RDMA, anche con multipath) viene associata 1:1 a un vDisk, che poi potrà essere usato in combinazione con altri vDisk (locali o remoti) come base per i cluster Ceph/MultiSCSI. Un vDisk che usa dischi remoti non ha nessuna limitazione rispetto a un vDisk che usa dischi locali, consentendo anche alle appliance TVStor di essere diskless, per esempio, per fare l’alta affidabilità di SAN esterne multi-vendor.
Cluster con engine Ceph
TVStor permette la creazione e gestione di uno o più cluster Ceph indipendenti. Per ogni cluster Ceph: si può fare deploy di MON/MGR/MDS distribuiti tra i vari nodi TVStor, si possono usare i vDisk come OSD (nota: un vDisk può essere usato solo in un modo: o come OSD di un cluster Ceph o come disco di un cluster MultiSCSI, e non può essere condiviso). Sui cluster Ceph si può inoltre controllare lo stato di salute dettagliato, si possono impostare flag sugli OSD, gestire la manutenzione dei servizi Ceph, si possono esplorare i pool esistenti (che vengono creati tramite la gestione volumi di TVStor, descritta più sotto) e gli oggetti dentro ai pool, si possono gestire le regole CRUSH e la CRUSHMAP. Ovviamente, un cluster Ceph fa uso di quorum, e necessita di almeno 3 nodi (consigliati almeno 5).
Cluster con engine TVStor MultiSCSI
TVStor MultiSCSI è un engine proprietario di TVStor, che si basa su tecnologie e formati open-source in modo da consentire la lettura dei dati anche senza TVStor. MultiSCSI ha le seguenti differenze operative rispetto a Ceph: funziona anche con uno o due nodi (e fino a 4 nodi) ed ha architettura active/standby (rispetto a Ceph che è in grado di erogare letture/scritture da tutti i nodi). Il funzionamento di TVStor MultiSCSI si basa su NVMe/TCP (o NVMe/RDMA) per la condivisione interna dei dischi locali tra i vari nodi, e fa uso di LVM e MDADM per la replica dei dati. La sicurezza dei dati è garantita da un sistema sofisticato di fencing (modello STONITH) che può fare uso, in cascata, di BMC/IPMI, UPS/PDU, e switch di rete, per isolare l’altro nodo in caso di failure. MultiSCSI permette di avere in questo modo cluster con tre nodi in grado di funzionare anche quando cadono due nodi. I cluster MultiSCSI possono opzionalmente fare uso di quorum al posto del fencing quando sono formati da tre o più nodi, oppure sono formati da due nodi ma con un witness esterno (software o hardware).
Gestione volumi
I volumi sono i contenitori di dati, che vengono usati per erogare gli storage a blocchi/oggetti/file. Un volume può essere creato sia su cluster Ceph sia MultiSCSI. Nel caso di Ceph, un volume viene materializzato sottoforma di pool o volume CephFS, a seconda che il volume viene usato per storage a blocchi/oggetti oppure a file. Nel caso MultiSCSI, i volumi vengono materializzati sempre sottoforma di blocchi (che in caso di storage a file vengono formattati normalmente, dato che MultiSCSI è active/standby e non necessita di filesystem distribuiti come GFS/OCFS). Appena creato, un volume rimane in attesa di essere materializzato nel momento in cui gli viene assegnato uno scopo (tramite la gestione LUN/bucket/filesystem); una volta materializzato, non potrà svolgere altri scopi, però rimane intatto in caso di distruzione del LUN/bucket/filesystem in modo da rendere esplicita la distruzione dei dati tramite eliminazione del volume. Sui volumi vengono applicate le policy QoS, di compressione, di crittografia a riposo, di replica e backup, ecc.
Gestione LUN, bucket S3 e filesystem
I volumi, di per sé, non vengono esposti esternamente così come sono, ma gli viene assegnato un ruolo/scopo. Un volume può essere trasformato in LUN, ed esportato contemporaneamente via iSCSI, NVMe/TCP, SCSI/FC, NVMe/FC, NVMe/RDMA, anche usando multipath; per ogni LUN si possono stabilire le ACL di connessione dall’esterno (whitelist IP, credenziali degli initiator, ecc.). Un volume TVStor può essere usato anche come bucket S3 per erogare oggetti anziché blocchi; anche in questo caso si possono stabilire le varie policy e credenziali di accesso al bucket S3. Infine, un volume può essere usato come filesystem, per poter essere esposto tramite protocolli NAS come NFSv3/4, CIFS/SMB, FTP/FTPS, TFTP, SFTP; nel caso dei filesystem, sono supportate ACL sia POSIX sia NT, con integrazione verso LDAP/AD esterni per l’autenticazione e i permessi.
Autenticazione e permessi utenti
Le appliance TVStor hanno sia un database interno di utenti locali (condiviso in tutto il cluster TVStor), sia la possibilità di autenticare gli utenti tramite un servizio esterno. L’autenticazione esterna può essere basata su LDAP/LDAPS (bind username+password), RADIUS (username+password, username+password+challenge, 802.1X EAP-TLS / EAP-TTLS-PAP / EAP-TTLS-GTC / EAP-PWD / EAP-PEAP-GTC), OpenID Connect (anche con device-code, PKCE, CIBA), SAML 2.0. Per quanto riguarda l’autenticazione a fattori multipli (MFA), per gli utenti locali TVStor è possibile configurare un MFA interno che fa uso di TOTP, oppure è possibile configurare un MFA esterno tramite un bridge/plugin. Per gli utenti non locali (LDAP/RADIUS/OIDC/SAML), l’MFA dev’essere configurato sul server di autenticazione esterna. Il login ai servizi esposti da TVStor avviene in maniera differente a seconda del servizio: in caso di LUN (iSCSI/NVMe TCP/FC/RDMA) e in caso di bucket S3, il login è tramite credenziali statiche configurate su TVStor. In caso di accesso alla dashboard TVStor, l’utente può fare uso di username/password, TOTP/challenge, e redirect OIDC/SAML a seconda di come è configurata l’autenticazione locale/esterna di quell’utente. In caso di filesystem (NFS/SMB/FTP/SFTP/TFTP) l’autenticazione cambia a seconda del protocollo.
Interfaccia web per esplorare i filesystem
Le appliance TVStor espongono, per tutti gli utenti che hanno accesso almeno a un filesystem, un’interfaccia web con la quale possono esplorare i file sulle share a cui hanno accesso, possono vedere l’anteprima nel browser di alcuni file prima di scaricarli (come immagini, video, PDF), possono caricare file e cartelle, possono scaricare singoli file o cartelle intere (sottoforma di ZIP), possono modificare dal browser documenti Office Word/Excel/Powerpoint (anche in modalità collaborativa). Tutto ovviamente on-premise, come il resto delle funzionalità TVStor.
Servizi di rete DHCP/PXE
Le appliance TVStor sono in grado di erogare servizi DHCP e PXE per consentire il boot da rete di apparati esterni, sfruttando i filesystem TFTP erogabili da TVStor. Il DHCP offerto da TVStor è solo DHCPv4, e TVStor è in grado di integrarsi anche con server DHCP già esistenti nell’infrastruttura, andando a modificare la configurazione delle options 66/67 (next-server e file di boot BIOS/UEFI) in modo da far atterrare gli apparati che fanno boot da rete presso il TFTP erogato da TVStor. Nel caso invece si voglia usare il server DHCPv4 integrato in TVStor, le funzionalità supportate sono: uno o più range di assegnazione, durata lease, default gateway opzionale (option 3), uno o più server DNS opzionali (option 6), dominio opzionale (option 15), e ovviamente le options 66/67 per il PXE.
Alta affidabilità e bilanciamento di carico
Un cluster TVStor è formato da una o più appliance TVStor. Se il cluster è formato solo da 1 nodo, non c’è alta affidabilità né bilanciamento di carico, l’unico engine usabile è TVStor MultiSCSI, che opera solo sui dischi locali dell’unico nodo oppure su dischi remoti di SAN esterne. Quando il numero di nodi è 2, l’alta affidabilità viene attuata tramite fencing STONITH: i due nodi sono configurati active/standby con replica sincrona della configurazione e dello stato; quando un nodo smette di comunicare con l’altro, tenta in primis di buttare giù il peer tramite diversi metodi in cascata (BMC/IPMI, UPS/PDU, switch di rete), usando un meccanismo che evita a due nodi in split-brain di buttarsi giù a vicenda; una volta che l’altro nodo è marcato come spento/isolato, il secondario prende ruolo di primario, oppure il primario continua senza più aspettare l’acknowledgment delle repliche sul nodo secondario. Questo meccanismo viene usato non solo per il database locale che contiene configurazione e stato, ma anche per le repliche dei dischi da parte dell’engine MultiSCSI. Quando si hanno due nodi, si può fare deploy di un TVStor Witness software o hardware per permettere al cluster di attuare l’HA tramite quorum anziché fencing.
Quando i nodi salgono a 3 e oltre, il ruolo di witness può essere ricoperto da uno dei tre nodi TVStor (questo vale sia per l’HA del database sia per l’HA dell’engine MultiSCSI). Opzionalmente, si può decidere di abilitare il fencing come fallback dentro un cluster solo-MultiSCSI di 3 o più nodi, per permettere di sopravvivere alla perdita di quorum (quindi un cluster TVStor di 3 nodi che usa solo MultiSCSI può usare il witness integrato per degradare velocemente quando perde un nodo su tre, e poi può fare ricorso al fencing per continuare a operare con un nodo su tre). Il bilanciamento di carico con l’engine MultiSCSI è ottenuto alternando i nodi primari di un cluster tra un nodo e l’altro (es. cluster di TVStor di due nodi, un cluster MultiSCSI ha primario nodo1 e secondario nodo2, e un altro cluster MultiSCSI ha primario nodo2 e secondario nodo1; collassano su un solo nodo solo quando c’è una failure o manutenzione). I cluster Ceph creati dentro TVStor invece ragionano diversamente: prima di tutto, necessitano di almeno 3 nodi (consigliati 5); il modello Ceph non è active/standby ma è perlopiù active/active, quindi il bilanciamento di carico è nativo in tutti i cluster Ceph; quando un cluster TVStor contiene cluster Ceph, non è possibile usare il fencing come meccanismo (quindi gli altri eventuali cluster MultiSCSI fanno uso solo di quorum per l’HA).
Qui sotto, la sequenza di un failover, animata.
Cluster sano: 5 oggetti, 3 copie ciascuno. Fai clic su un nodo per spegnerlo.
Appliance TVStor diskless e HA di SAN esterne
Un cluster TVStor è in grado di fornire alta affidabilità a SAN esterne (anche multi-vendor), sfruttando il fatto che un’appliance TVStor può usare come vDisk anche LUN esterne, permettendo anche configurazioni effettivamente diskless di un’appliance. Un esempio di architettura: sul rack1 abbiamo una SAN san1 del vendor1, sul rack2 abbiamo una SAN san2 del vendor2; installiamo due SAN TVStor diskless, san3 e san4, una in ogni armadio rack, e le configuriamo in modo da fare HA per le SAN san1/san2 già esistenti; in questo modo gli applicativi esterni si collegano alle SAN TVStor san3/san4 anziché a quelle già esistenti, e in caso in cui un armadio rack va giù, l’HA erogata da TVStor permette agli applicativi esterni di continuare a raggiungere le LUN/ecc. delle SAN san1/san2.
Gestione multi-tenant
TVStor mette a disposizione una suddivisione opzionale in tenant, per permettere a determinati utenti di amministrare solo una porzione di infrastruttura storage. Ai tenant possono essere assegnati quote di utilizzo disco e QoS, e per ogni tenant si può specificare quali sono le funzionalità abilitate (tra LUN, bucket S3, e filesystem). Un tenant non può amministrare cluster Ceph o MultiSCSI, può solo creare volumi (nei limiti delle quote e sui cluster consentiti) e gestire i servizi esposti sui volumi (ad eccezione del DHCP/PXE). Le policy di compressione, crittografia, backup e replica sui volumi di un tenant possono essere decisi o dall’amministratore TVStor o delegati parzialmente all’amministratore del tenant.
Backup, replica e protezione dei dati
Backup e replica
Repliche sincrone fra i nodi, o erasure coding sul motore Ceph, con domini di guasto consapevoli
Replica remota asincrona verso un secondo cluster TVStor, per il disaster recovery
Backup incrementali intelligenti (CBT): viaggiano solo i blocchi cambiati, verso repository locali o S3, con restore a catena
Backup immutabili, anche per gli admin: in governance la nostra API rifiuta la cancellazione a chiunque, admin compresi; compliance aggiunge l’S3 Object Lock. Le retention emesse non si accorciano mai, confine onesto: dentro la SAN garantiamo noi, fuori la cifratura
Ricostruzione automatica alla perdita di dischi o nodi, con sostituzione del disco guidata
Failover dimostrato, non promesso: fencing a cascata, BMC, switch, PDU, e terzo voto witnessd (gli basta un Raspberry): nessuna scrittura confermata persa, mai due primari
Sicurezza operativa
Crittografia a riposo e in transito, di serie: LUKS2 e dm-crypt, chiavi AES-256-GCM in cassaforte, sblocco al boot non presidiato
Appliance blindata: niente accesso SSH di default; credenziali d’emergenza e chiavi di ripristino della cifratura nascono per la cassaforte, sotto supervisione
Volumi protetti: un volume mappato non si cancella per sbaglio, servono conferme esplicite
Ruoli e audit: deny-by-default, deleghe, e ogni operazione ricostruibile
Aggiornamenti rolling: la manutenzione scorre nodo per nodo, i volumi restano serviti
Monitoraggio e alert integrati su capacità, salute e latenze, con trend di riempimento
Crittografia, immutabilità e failover dimostrato sono di serie, non opzioni a listino: per difesa, pubblica amministrazione e sanità, la protezione è parte del progetto.
Appliance TVStor in bundle
Un’idea sola: il mattone, un server standard completo, x86 o ARM, con tutte le funzioni TVStor. Da solo, in coppia in mirror su rack separati, o in cluster: le topologie le componi tu. E ogni sigla del codice dichiara ciò che conta.
appliance, hardware di 1ª gen.
mattone a nodo singolo
NVMe U.2 PCIe 5.0 · DWPD 1
Codici media: U2 = NVMe U.2 · M2 = M.2 NVMe · ST = SSD SATA3 · HD = HDD 7200 rpm (M/H = WRL medio/alto) · D1/D3/D5 = DWPD
| CODICE | MEDIA | DWPD | VOCAZIONE |
|---|---|---|---|
| TVSTOR-AG1-N1-U2D1 | NVMe U.2 PCIe 5.0 | 1 | Capacity, letture e carichi misti |
| TVSTOR-AG1-N1-U2D3 | NVMe U.2 PCIe 5.0 | 3 | Write-Intensive, scritture continue |
| TVSTOR-AG1-N1-M2D1 | M.2 NVMe | 1 | Capacity in formato compatto |
| TVSTOR-AG1-N1-M2D3 | M.2 NVMe | 3 | Write-Intensive in formato compatto |
| TVSTOR-AG1-N1-STD5 | SSD 2,5" SATA3 6G | 5 | Endurance estrema, canale SATA |
| TVSTOR-AG1-N1-HDM | HDD 3,5" 7200 rpm SATA/SAS | — | Capacità fredda, WRL 100-250 TB/anno |
| TVSTOR-AG1-N1-HDH | HDD 3,5" 7200 rpm SATA/SAS | — | Nearline enterprise, WRL fino a 550 TB/anno |
Il codice dichiara media ed endurance, mai i terabyte: la capacità si configura per progetto, e le scritture/giorno si calcolano da soli (DWPD × capacità installata). La coppia in mirror su rack separati, la forma di riferimento, è l’allineamento onesto a un dual-controller «da 50 TB grezzi»: 35-40 TB utili reali. Altre forme e media: su progetto.
Da solo
capacità pura su un server standard, con tutte le funzioni e la console TVStor.
In coppia
mirror sincrono su rack separati, RAID 5 locale e fencing automatico: la SAN di riferimento della generazione AG1.
In cluster
topologie multi-nodo e motore Ceph, su progetto.
In coppia, la protezione è a tre strati: il RAID 5 locale assorbe il guasto di un disco senza toccare la replica; il mirror sincrono fra i rack assorbe la perdita di un server intero; il fencing automatico esclude un lato prima che le copie possano divergere, mai due primari. Telai, alimentazioni, ventole e rack: tutti separati.
L’endurance sta nel nome del prodotto. Nei preventivi che confronterai, spesso non sta da nessuna parte: chiedi al fornitore di scrivere il DWPD dei suoi dischi, per iscritto.
Per ogni appliance chiavi in mano, le espansioni possibili, tipologie, limiti e prezzi, sono definite per iscritto dal giorno uno. La crescita non è una trattativa: è una riga di contratto che hai già letto.
TVStor e le alternative
Ogni alternativa qui sotto è un prodotto serio, con punti di forza reali. Il confronto però non è la scheda tecnica: è il modello, architettura, modello commerciale, e dove restano i dati di casa.
| PIATTAFORMA | CONTROL PLANE | MODELLO DI LICENZA | DA CONSIDERARE |
|---|---|---|---|
Trantor® TVStor Trantor® · Italia | Appliance software a doppio motore (Ceph o MultiSCSI): da due nodi allo scale-out, su server standard | Chiavi in mano su server standard, o installata sui tuoi: hardware sempre tuo e sostituibile | Crittografia a riposo e in transito, backup immutabili a prova di admin, crescita nodo per nodo, formati aperti: la SAN senza il suo lock-in |
NetApp ONTAP · extra-UE | Coppie di controller ONTAP in HA su appliance dedicate | Appliance proprietarie; software a bundle, consumo e STaaS (Keystone) | Ecosistema vastissimo, SAN e NAS unificati; hardware, shelf e ricambi restano un binario del vendor |
Pure Storage FlashArray · extra-UE | Array a doppio controller con moduli flash proprietari (DirectFlash) | Subscription-first (Evergreen), fino allo storage as-a-service | Esperienza operativa curatissima; l’hardware è proprietario fino al singolo modulo flash, e l’uscita è una trattativa |
QSAN XCubeSAN · extra-UE | Array a doppio controller di fascia value | Appliance a listino, licensing semplice | Prezzo aggressivo per il mid-market; scale-up classico: la crescita passa dagli shelf e dalle espansioni del vendor |
HPE 3PAR StoreServ · extra-UE | Mesh multi-controller, scale-up su appliance dedicate | Fuori listino dal 2021; supporto in esaurimento (2026–2027) | Linea storica a fine corsa: HPE indica Alletra come successore. Il refresh è comunque in agenda, tanto vale ripensare il modello |
QNAP · Synology NAS SMB · extra-UE | NAS a nodo singolo o in coppia: filer prima che SAN | Appliance a listino, ecosistema di app | Ottimi filer di fascia SMB; l’HA enterprise e i blocchi non sono il loro mestiere |
Nextcloud File e collaborazione · Germania | Sync e collaborazione sopra uno storage che porti tu | Open source; enterprise in abbonamento | Riferimento della collaborazione sovrana, ma è un’app: la SAN sotto resta un altro progetto |
IBM SVC Storage Virtualize · extra-UE | HA-gateway e virtualizzatore davanti a SAN di terzi | Appliance dedicate, licenze a capacità | Il riferimento storico del mestiere HA-gateway; TVStor lo fa su formati aperti, senza appliance dedicata |
HPE Alletra MP / GreenLake · extra-UE | Linea attuale HPE: architettura MP disaggregata, eredi di Primera e Nimble | Appliance proprietarie; spinta commerciale su GreenLake, subscription e consumo | Il successore designato di 3PAR: moderno e curato, ma il modello è lo stesso, hardware del vendor, contratti pluriennali. La giostra riparte |
Posizionamento sintetico aggiornato a luglio 2026. Ogni piattaforma citata è un prodotto valido nel proprio contesto d’uso; i marchi appartengono ai rispettivi proprietari.
- «Quando dovrò espandere, potrò comprare l’hardware da chiunque, o solo da voi?»
- «Oltre lo sconto di oggi: quanto mi costeranno espansioni e rinnovi fra tre anni?»
- «Se decidessi di lasciarvi, quanto sarà complesso portare via i miei dati?»
TVStor risponde per iscritto.
Zero lock-in. Made in Italy.
Progettata e sviluppata in Italia dalla stessa squadra della famiglia Trantor: chi ti supporta è chi ha scritto il codice, con un interlocutore unico per prodotto, roadmap e assistenza.
Libertà su quattro assi
Hardware: server e dischi standard, nessuno shelf proprietario, nessun vendor obbligato, nemmeno noi: anche l’hardware fornito da Trantor è standard e sostituibile
Dati: motori su formati aperti, Ceph da una parte, MDADM + LVM + NVMe/TCP dall’altra: i dischi restano leggibili su altre piattaforme, non solo con la nostra console
Client: gli host si collegano con initiator e driver nativi dei loro sistemi operativi, niente agent proprietari da mantenere
Crescita: si scala e si dismette nodo per nodo; il forklift upgrade non è un appuntamento in calendario
Made in Italy, davvero
Progettata e sviluppata in Italia dalla stessa squadra della famiglia Trantor: chi ti supporta è chi ha scritto il codice, con un interlocutore unico per prodotto, roadmap e assistenza. Una risposta concreta ai requisiti di sovranità tecnologica e riservatezza di difesa, pubblica amministrazione e grandi gruppi: lo storage dei tuoi dati non dipende da decisioni prese oltreoceano.
Crittografia e backup immutabili
Ogni disco è cifrato a riposo, un disco estratto o dismesso non racconta nulla, e ogni comunicazione fra i nodi viaggia cifrata in transito. I backup immutabili, intoccabili fino a scadenza, anche per un amministratore, chiudono la porta al ransomware. Per difesa, PA e sanità, la protezione è parte del progetto, non un modulo.
La famiglia Trantor®
TVirt© per la virtualizzazione di VM e container, TVStor per lo storage, VDesk per le postazioni di lavoro virtuali: tre prodotti, una filiera italiana, un solo interlocutore per l’intera infrastruttura.
TVirt per la virtualizzazione di VM e container, TVStor per lo storage: una filiera italiana, un solo interlocutore.
VDesk per le postazioni di lavoro virtuali, TVStor per lo storage: una filiera italiana, un solo interlocutore.
Ultimo aggiornamento: 10 agosto 2026. I contenuti di questa pagina sono allineati alla brochure di quella revisione.
Vedila in azione.
Richiedi una demo guidata o un proof of concept sul tuo hardware, in laboratorio o nel tuo datacenter.