Disque partagé dans le centre de données moderne (SAN, virtualisation, etc.)

Je suis un développeur … en train de marcher ici sur un terrain étranger. Veuillez pardonner toute naïveté.

Je travaille sur une application qui stocke datatables à la fois dans une database et dans le système de files.

Context: regroupement et partage de réseau

Dans le passé, lorsque nous avons exécuté l'application regroupée (c'est-à-dire plusieurs servers d'applications devant datatables), nous avons traité le système de files comme suit:

  • Nœud A: partage le "directory de données" (via samba ou nfs)
  • Nœuds B, C, D, etc: monte le "partage réseau" et l'utilise à son "directory de données"

La "vitesse du disque" réduite pour les noeuds B, C, D était sous-optimale, mais pas un gros problème.

Notez également : l'application utilise son propre mécanisme de locking de file. Les écrits simultanés ne sont pas un problème.

Questions

  • Ainsi, dans un centre de données moderne, le canal de fibre relie les servers à SANS, quelle est la meilleure façon de partager un «disque de disque» parmi plusieurs servers?

  • Un tel «partage de disque» est-il largement utilisé?

  • Toutes les préoccupations spécifiques au operating system ("fonctionne sur linux, mais pas disponible sur Windows")

  • Des mises en garde? Difficile de configurer, peu fiable, etc.?

J'ai entendu beaucoup de "nous ne pouvons pas le faire" à partir de nos sysadmins … enfin, quand j'ai demandé plus de détails, ils ont dit "bien, techniquement, c'est possible, mais ce n'est pas ainsi que nous le faisons ici"

Merci d'avance,

Mise à jour: Merci pour les réponses. (Ils étaient tous bons: il fallait en choisir un. Désolé si ce n'était pas le vôtre) Juste comme je l'avais attendu (un peu): j'espère que vous pouvez simplement attacher NTFS ou XFS ou n'importe quel système de files "régulier" au même de «disque» s'est révélé naïf. Le système de files en cluster est le ticket. Et les filesystems sophistiqués ne sont pas sur les principales priorités de notre équipe d'hébergement).

3 Solutions collect form web for “Disque partagé dans le centre de données moderne (SAN, virtualisation, etc.)”

"Bien, techniquement, c'est possible, mais ce n'est pas ainsi que nous le faisons ici"

Cela ressemble beaucoup à ce que je dis régulièrement aux développeurs;)

Du sharepoint vue opérationnel d'une entreprise, vous voulez autant que possible que les applications utilisent des solutions répétées standard. Si votre request n'a pas besoin d'un traitement spécial, vous ne l'obtiendrez pas. Les solutions non standard requièrent des compétences spécialisées, des équipements plus coûteux ou plus simples et, si c'est un état de l'art, les pannes sont souvent catastrophiques.

Pour de nombreuses applications, un partage de files (hautement disponible) est toujours une solution très appropriée et déployée de manière courante.

Les solutions alternatives de HA communes à l'utilisation d'un file-partage sont:

  • Ne stockez pas de files sur les filesystems, mais utilisez une database hautement disponible et les stockez en tant que BLOB à la place. Une approche très commune. Souvent, vous avez déjà besoin d'une database de toute façon, ce qui rend les servers d'applications presque apasortingdes, résout beaucoup de problèmes de locking, de réplication, de cohérence et d'access, en les transférant dans la couche de database, où beaucoup de ces problèmes sont des nouvelles anciennes, bien comsockets et résolu. Il peut être coûteux de maintenir, mais une fois que vous atteignez (une fraction importante) de la gamme petabyte.

  • Un système de files groupés approprié, qui permet l'access simultané au niveau du bloc de lecture-écriture à votre stockage partagé sur Fibre Channel ou iSCSI. Les arrays de stockage d'entreprise ont tendance à être assez coûteux, mais cela peut très bien s'aligner. Souvent, le système de files de cluster requirejs des licences (coûteuses) pour chaque nœud pour le logiciel de cluster FS. Il est également très courant dans les environnements d'entreprise pour des applications spécialisées.

  • Utilisez un magasin d'object dissortingbué. Il s'agit de la solution open source, du matériel de base bas de gamme, de la création de redondance et de l'évolutivité dans le logiciel. Il s'agit d'une approche commune «nuage».

Si vous connectez plusieurs servers à un périphérique de bloc partagé (DASD / SAN), vous devez toujours gérer manuellement l'access aux blocs de disque (certaines bases de données le font sur des disques bruts, LVM est également une option, avec access LV géré) ou utiliser un système de files de cluster, qui gérera l'access simultané.

Même avec les serrures d'écriture gérées par file, vous risquez d'avoir une corruption de FS sinon, si deux hôtes tentent d'effectuer des modifications de métadonnées FS en même time, sur un FS non groupé. Rien de moderne à ce sujet, BTW, SAN et access simultané aux blocs ont été autour depuis les années 80 (sinon les années 70).

Tous les systèmes d'exploitation modernes ont mis en place des implémentations FS, et l'isolation des blocs de blocs est également possible si vous êtes prêt à écrire tout vous-même, donc c'est très précis à ce que vous souhaitez utiliser.

EDIT: votre "vieille" approche de partage de réseau est encore assez faisable, et le server de files prend soin des serrures de files, donc vous n'avez pas besoin de mécanismes de locking supplémentaires. Si vous n'êtes pas après une performance supplémentaire et que vous souhaitez un deployment simple, c'est probablement encore l'itinéraire le plus simple.

Maintenant, si vous voulez parler de «moderne», commencez à penser au stockage des objects et à l'architecture de votre application.

Vous n'avez besoin que du matériel partagé, mais aussi d'un système de files en cluster.

Les filesystems réguliers ne fonctionneront pas – deux ordinateurs finiraient par écraser les autres changements, et vous finirez par un système de files corrompu.

Les filesystems en cluster ont tous les ordinateurs qui s'entendent mutuellement sur les changements qu'ils produisent, et manipulent les files de locking au besoin pour qu'ils ne se penchent pas sur les doigts de l'autre.

Certains de ces filesystems sont spécifiques à l'application – VMware possède VMFS par exemple, et Hyper-V a des volumes partagés partagés – ils fonctionnent bien pour stocker des machines virtuelles, mais ne sont pas considérés comme un stockage général de files. Il y a d'autres qui sont conçus pour stocker tous les files. Chacun présente divers avantages et inconvénients, de sorte que le mieux dépend fortement de ce que vous faites avec lui. Ils sont tous (autant que je le sais) OS spécifiques – vous ne pourrez pas partager un système de files entre Windows et Linux de cette façon.

Pour certaines choses comme le basculement de la machine virtuelle haute disponibilité, vous avez vraiment besoin de cela. Pour les applications où SMB ou NFS fonctionnent, ceux-ci sont généralement préférés: ils peuvent être légèrement plus lents, mais il y a beaucoup less de choses qui pourraient aller mal et plus faciles à récupérer lorsqu'elles se brisent.

  • Existe-t-il un SAN / Storage Storage Dissortingbuted?
  • Système de files de stockage partagé open source?
  • Échecs d'allocation de page sur le stockage iSCSI
  • Comment faire pour get SAN comme une flexibilité d'un NAS?
  • Utilisation d'un LUN non formaté de plus de 2 To dans le magasin de stockage ESXi local
  • EMC ESRS cesse de fonctionner lorsqu'il est VMotioned
  • VMware VMFS5 et dimensionnement LUN - plusieurs banques de données plus petites, ou 1 grande banque de données?
  • Fusionner les hôtes VMware en direct dans le vcenter existant
  • Les données resortingving sur SAN sont-elles rapides par rapport au stockage sur un disque local?
  • Routage utilisant des commutateurs au lieu du routeur
  • Interprétation du nombre de crédits de transmission zéro
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.