Egalement, par rapport au temps nécessaire pour la reconnexion. 

Un exemple d'un client ayant une infrastructure un peu plus légère que la tienne, 450VM environ et 40To sur une archive (une fois dédup + compress). La reconnexion prend plus d'une semaine. 

Donc si tu veux alléger ces temps de reconnexion je te conseille de découper tes archival locations pour isoler tes VMs critiques nécessitant des restaurations plus rapides en cas de PRA. Ça te forcera par la même occasion à les mettre dans un SLA séparé. 

Comme ça en cas de bascule, tu peux reconnecter uniquement l'archival location de tes VMs critiques et procéder à tes restaurations beaucoup plus rapidement.

Le 6 février 2018 à 20:59, Lucas Fueyo <lucas.fueyo@gmail.com> a écrit :
Ça n'est pas vraiment une reconstruction des archival locations mais plutôt une reconnexion à l'archival location. 

Les données en elles mêmes ne sont pas modifiées, mais le cluster Rubrik va scanner toutes les metadata de l'archive pour pouvoir te permettre d'effectuer des restaurations à partir de ces archives. (ce qui peut prendre du temps, beaucoup de temps)

Hors PRA, les seuls cas que je vois sont lors d'un changement du stockage utilisé pour l'archivage. 

Par exemple, passage d'une appliance de déduplication à une appliance de déduplication plus récente avec des rétentions de backup trop longues pour attendre leur expiration. Dans ce cas tu répliques tes données sur la nouvelle appliance et tu reconnectes ce réplicat en RO pour pouvoir effectuer tes restaurations.

Même chose dans le cas d'un changement de cloud provider (vu chez un client qui hébergeait ses données chez un cloud provider US => Pour pouvoir afficher à ses clients qu'il respectait la GDPR il a dû replacer ses données dans un stockage S3 Européen).

C'est les seuls cas que je vois hors PRA / perte d'un cluster Rubrik / perte de ton stockage primaire d'archivage.

Merci, 

Le 6 février 2018 à 20:32, professor geek <prg33k@gmail.com> a écrit :
Merci Lucas pour ce retour, ca m’aide un peu à y voir plus clair et verifier l’adéquation avec l’application à protéger.
Pour oracle nous utilisons deja la règle des x4. 
L’intégrateur nous a parler de la possibilité de mettre les 2 outils dans ServiceNow pour le self backup/restore, le provisioning des VM et le monitoring.

Tu as eu le cas de devoir reconstruire tes Archivals locations hors PRA? 
Ca me rappelle des mauvais souvenir avec TimeMachine ;)
Vu les volumes a protéger, ca peut prendre un certain temps !

Pr

On 6 February 2018 at 19:04:53, Lucas Fueyo (lucas.fueyo@gmail.com) wrote:

Hello, 

Globalement pour Nutanix je ne vais pas avoir un retour très approfondi à te faire. Juste attention aux coûts de licences en AHV si tu veux avoir les mêmes fonctionnalités qu'un VMware classique. 

Pour le Rubrik, pas rapport à un NetBackup c'est le jour et la nuit pour l'interface de management, et j'aurais vraiment tendance à préférer Rubrik. (sous certaines conditions) 

Il faut que ton infrastructure soit vraiment adaptée à Rubrik : 
- Pas de RDM en physical (normal pour les snapshots)
- Pas de scsi bus sharing (normal pour les snapshots)
- Pas de cluster applicatif excepté SQL (sinon tu essayes de lancer les snapshots en même temps et tu pries lors de la restore, donc autant passer par le système de backup de ton applicatif)
- Pas besoin d'avoir une sauvegarde calendaire (sauvegarde effectuée un jour spécifique de la semaine)
- Pas besoin d'avoir une sauvegarde lancée à une heure précise 
- Pas besoin de BMR, il faut que tu sois sur du full VM (ça gère aussi les physiques, pas d'inquiétude là dessus, mais  la matrice de compatibilité est réduite donc si tu veux sauvegarder du sparc tu peux oublier)

Sinon si tu rentres dans ces cas de figure, tu vas devoir scripter via leur API Rest pour lancer les backups au moment où tu le souhaites exactement, et là tu perds l'un des gros intérêts de la solution qui est son scheduler. Le gros de ton travail d'un point de vue client sera vraiment sur la définition de tes SLAs.

Egalement, si tu veux effectuer de la sauvegarde Oracle avec du RMAN ça peut rapidement t'utiliser beaucoup d'espace de stockage (les best practices : 4 fois la taille de ta base pour gérer tes backups).

Petite chose si tu effectues de l'archivage pour tes PRA, il faut savoir que l'on ne peut reconnecter des archival locations qu'en RO. Donc si tu fais une bascule PRA => tu devras créer une nouvelle archival location et donc relancer une nouvelle full sur ton NFS / S3.

Enfin, l'un des point sensible est la supervision de la solution. L'alerting mail est relativement satisfaisant pour les jobs et l'état hardware (c'est du supermicro derrière), mais si tu veux mettre en place du SNMP ça n'est pour l'instant pas supporté. Il faudra attendre quelques mois. 

Je parle de beaucoup de points noirs car les bienfaits de la solution t'ont de toute façon déjà été présentés par le marketing. 

C'est vraiment une très belle solution, qui évolue rapidement et dans la bonne direction et si effectivement tu souhaites pouvoir intégrer facilement ton environnement de sauvegarde à un orchestrateur / un portail de self-service homemade... Rubrik répondra parfaitement à ce besoin. Il faut juste être conscient de certaines limites du système, comme tout soft de backup.

On peut en discuter en MP si tu le souhaites.

Merci, 

Le 6 février 2018 à 18:42, professor geek <prg33k@gmail.com> a écrit :
Hello la liste,

Un de vous aurez un retour d’experience sur une implementation de NUTANIX / Rubrik ?
On nous propose ce système en remplacement du classique VMware / vcenter / Api avec du san 3PAR le tout sauvegardé par NetBackup.
L’objectif est de remplacer une infra de 600vm, 1200 cores et de 14Tb de RAM avec un SAN de 300TB pour avoir une meilleure integration avec des outils DevOps.

N’ayant pas trop eu l’occasion d’utiliser ce type de système si une bonne âme aurait une version non marketing avec un vrai retour d’expérience ;)


Thanks,

Pr



_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/