Un autre rôle Azure peut-il lire des données de disque non écrites laissées par mon rôle lorsque mon rôle de machine virtuelle Azure est récupéré?

Supposons que mon rôle Azure stocke certaines données sur le disque local de la machine virtuelle, puis se termine. Le disque local a été mappé sur un stockage physique et les données stockées sur le disque local ont été écrites dans ce stockage. Lorsque mon rôle se termine, la machine virtuelle est récupérée et le stockage physique est également récupéré.

Maintenant, un autre rôle est démarré et son disque local se trouve être mappé sur le même stockage physique que celui utilisé dans mon rôle. Je sais bien que la structure logique du nouveau disque local est complètement reconstruite et que tous les fichiers éventuellement laissés par mon rôle disparaîtront . Cependant, le stockage physique sous le disque logique nouvellement créé est identique.

Supposons spécifiquement que le nouveau rôle crée un fichier vide, puis appelle SetEndOfFile () pour “étendre” le fichier, puis l’ouvre pour lire et lit les données actuellement stockées sur le disque logique. À moins que des mesures spéciales ne soient sockets dans l’infrastructure Azure, je ne suis pas sûr que cela n’entraînera pas l’extension du fichier par rapport aux données stockées par mon rôle et la lecture de ces données.

Est-il techniquement possible pour le nouveau rôle de lire les données écrites par mon rôle?

La réponse courte est non,

Toutes les requêtes d’E / S provenant de l’OS invité sont gérées par l’hyperviseur. L’hyperviseur garantit qu’une entrée ne peut accéder qu’au stockage affecté.

La seule façon d’accéder aux données des anciens rôles est d’avoir un access physique dans les conteneurs et de les récupérer à partir de là (si vous réussissez à faire passer les mesures de sécurité physique des centres de données et dans les conteneurs scellés). pour être simple, sachant que les disques logiques ne mappent pas un à un sur des disques physiques individuels, mais sur des groupes de disques, vos données seront également dispersées physiquement sur plusieurs disques.

En outre, des procédures d’élimination officielles garantissent que toutes les données sont supprimées des disques en cours de mise au rebut.

Cordialement, Yves

+1 à @Yves et oui la réponse est NON.

Je voudrais append plus d’informations sur la façon dont les lecteurs virtuels sont créés et utilisés dans n’importe quelle machine virtuelle Windows Azure. Comme vous le savez peut-être déjà, chaque rôle (Web ou Worker) contient au minimum 3 lecteurs virtuels:

Lecteur E: est un lecteur d’application de 1 Go de taille fixe et créé dynamicment par FC à l’aide du Package mis à jour par l’utilisateur. Ce lecteur n’est pas conçu pour contenir des données utilisateur. Ce lecteur est créé par déploiement d’utilisateur pour qu’il soit nouveau pour chaque rôle. Ce lecteur est fourni à la machine virtuelle Azure par FC et connecté à la machine virtuelle au moment de la mise à disposition.
Drive D: est le lecteur OS / SYSTEM (environ 25 Go de taille) qui est attaché au rôle et identique à chaque rôle dépend de la version du système d’exploitation. Ceci est prêt à conduire uniquement au rôle Web, mais la tâche de démarrage et le rôle de travail peuvent y écrire. Le lecteur est dédié aux lecteurs de système d’exploitation et considère que l’utilisateur ne doit pas y placer son contenu.
Lecteur C: lecteur utilisateur dans lequel se trouvent les données utilisateur. Lorsque vous avez un stockage local dans votre application, le stockage est créé ici. Ce lecteur est créé virtuellement en fonction de la taille de la machine virtuelle du rôle.
- Sur une machine hôte Windows Azure, vous pouvez créer une petite machine virtuelle ou une machine virtuelle de très grande taille. Ainsi, votre machine virtuelle recevra environ 250 Go de disque dur ou 2 To de disque et ce stockage sera acquis depuis la machine hôte.
- Sur l’ordinateur hôte, des tas de disques sont connectés pour fournir un grand espace logique afin de répondre aux exigences de stockage local de taille de machine virtuelle de taille petite à grande. Lorsque le rôle VM est configuré, en fonction du type de rôle créé par la machine virtuelle sur l’hôte, un disque dur virtuel est créé à partir de l’espace logique total et associé à la machine virtuelle en tant que lecteur utilisateur.

Lorsqu’il y a une mise à jour du SE invité ou une mise à jour d’application Azure:

La mise à jour se produit dans le lecteur D: via l’image Diff
La mise à jour se produit dans le lecteur E: via Diff Image
Étant donné que le lecteur C est un lecteur utilisateur et que «Stockage local» n’est pas directement affecté par la mise à jour ou la mise à jour des rôles, la propriété Local Storage sera nettoyée lorsque le rôle sera recyclé.

Que se passe-t-il lorsque vous supprimez votre application d’Azure:

Le lecteur OS D: / lecteur Diff est supprimé
Le lecteur Application Drive E: / Diff est également ignoré
User Drive C: est supprimé et l’espace est réclamé par la machine hôte.
- Maintenant, quand une nouvelle machine virtuelle est créée sur la machine hôte, un nouveau lecteur utilisateur C: est créé et l’espace est alloué depuis l’espace physique disponible.
- Même lors de la prochaine mise en service d’une VM invitée extra-large sur la machine hôte, qui requirejs une taille de disque virtuel maximale de 2 To, le disque dur virtuel est reconstruit à partir de zéro. Donc, les disques virtuels de 2 To pour la machine virtuelle XLarge ne sont toujours pas identiques.
- Il n’y a donc aucune chance que vos anciens fichiers puissent être récupérés à partir du disque précédent, même lorsque vous utilisez l’API du système de fichiers que vous avez mentionnée dans votre question ci-dessus.

(Désolé pour l’écriture de gros post)