Oracle: 1 grand server vs. 2 petits servers?

Nous sums en train de planifier la mise en place de notre environnement de production Oracle 10gR2. Notre budget nous permet d'acheter 2 licences de processeur d'Oracle DB Standard Edition. Nous avons une expérience minimale avec Oracle, alors je vais me référer à quiconque l'a utilisé. Nous essayons de décider si nous devrions configurer une seule boîte quad-core double ou 2 boîtes quad-core individuelles dans une configuration RAC.

Notre DB en ce moment est d'environ 60 Go, et à notre apogée, nous aurons jusqu'à 150 users simultanés. La plupart des gros trucs se font par traitement par lots la nuit.

Mon intestin me dit qu'avoir 2 boîtes dans une configuration RAC ne peut pas être une mauvaise chose car elle fournit une véritable solution de basculement matérielle. DB stocké dans un LUN partagé sur un SAN via iSCSI. De plus, si nous avons besoin d'append de la capacité, nous disposons déjà de boîtes qui peuvent être mises à niveau avec des procs supplémentaires (je supposer avec un time d'arrêt nul, car il est configuré dans une configuration RAC) si nous ajoutons des licences supplémentaires ou RAM.

Est-ce que le CCR a des pénalités de performance? Est-ce que cela appenda une latence supplémentaire? Y a-t-il un véritable avantage pour avoir des boîtes à processeurs multiples fonctionnant sur ces systèmes? Si nous construisons les boîtes Oracle avec du matériel spécial: maps iSCSI matérielles, TOE NIC, ces boîtes seront solides? Nous déployons sur Windows 64 bits.

Alors, que feriez-vous? Une boîte ou deux?

Deux choses que je considérerais avec attention:

1) Le support 10gR2 commence déjà à tomber de la falaise de maintenance. Dans environ un an, il deviendra TRÈS coûteux d'get des correctifs, et Oracle a déjà déclaré que les derniers correctifs publics seront publiés à l'été 2010. Existe-t-il une raison pour laquelle vous n'utilisez pas la version 11 dans la construction d'un nouveau server?

2) RAC / Data Guard est en fait assez douloureux pour l'installation et la maintenance. Non seulement cela nécessite des licences Enterprise (beaucoup plus cher que la licence standard), votre OS server doit également être l'édition Enterprise et être configuré dans un cluster Windows.

Personnellement, si vous pouvez tolérer le potentiel d'une courte période d'indisponibilité / une perte potentielle de données, vous êtes beaucoup mieux avec la boîte unique, idéalement, avoir un server "en veille" pouvant être activé. Ce ne sont que mes opinions, et je suis sûr qu'elles peuvent être contestées, mais vraiment, un DB de 60 Go avec 150 users de pointe n'est plus aussi grand. La double boîte quad-core sera probablement meilleure que la configuration RAC, bien sûr, si vous mettez le double de la RAM dans la seule boîte.

Gardez-le simple si possible. Une boîte est meilleure que beaucoup pour la plupart des applications de database, sauf si vous avez des raisons spécifiques – telles que les performances.

L'échec du matériel est beaucoup less susceptible de générer des time d'arrêt que quelque chose qui se brise en raison d'une erreur de configuration. La configuration plus simple sera généralement payante en ayant less de modes d'échec. Vous pourriez constater que vous obtenez un système plus fiable en pratique avec un seul server et une simple database répliquée sur une machine en attente.

N'allez pas pour un SLA plus serré que vous avez vraiment besoin et ne créez pas un système avec une complexité supplémentaire pour atteindre un SLA qui n'est pas pris en charge par tous les aspects du logiciel, des opérations et du matériel.

Une vision légèrement différente de la fiabilité de «cinq nains».

Sans doute, votre fournisseur revendiquera des statistics de fiabilité printingnantes pour son produit. À titre de countur, voici une «nine» portant sur différents niveaux de SLA à ce qui est réellement nécessaire pour les réaliser en pratique:

  • Deux nains (99%) se traduisent par une période DR de 24 heures et peuvent être pertinents pour les applications telles que les systèmes d'entrepôt de données où le système ne supporte pas directement les process opérationnels. Ce niveau de service est atteint en rétablissant le système à partir des sauvegardes.

  • Trois nains (99,9%) correspondent à une window DR de 4 heures et est vraiment tout ce qu'il faut pour la plupart des applications métier. Ce type de stratégie DR peut être réalisé avec une simple réplication d'expédition de journal et un server de secours. Souvent, la simplicité de ce type d'architecture signifie qu'il dispose de relativement peu de modes de défaillance basés sur la configuration et permet une meilleure fiabilité dans la pratique. Il existe de nombreux exemples d'applications 4GL à deux niveaux qui permettent de maintenir des time de fonctionnement continus de plusieurs mois ou des années avec ce type de configuration.

  • Quatre nains (99,99%) peuvent être visualisés comme une window DR de quelques minutes, et nécessitent une architecture hot-standby ou hot failover. La réalisation de ce type de SLA dans la pratique est assez difficile et nécessite généralement un logiciel conçu pour cela. Ironiquement, la complexité supplémentaire des architectures N-tier en cluster ouvre une surface beaucoup plus large des modes d'échec en raison d'une mauvaise configuration ou des glissades dans la gestion des changements.

    Il convient de noter que les erreurs de configuration et la mauvaise gestion des changements sont les causes majeures des time d'arrêt imprévus dans les opérations du centre de données et sont beaucoup plus susceptibles de provoquer une interruption imprévue que l'échec matériel sur un server.

  • Cinq nuits (99,999%) ne nécessitent pas plus de quelques secondes de time d'arrêt imprévu chaque année. Ce type de SLA vous met dans le domaine du matériel spécialisé et du logiciel construit pour la tolérance aux pannes. La mise en œuvre de ce type de SLA est coûteuse, nécessite une plate-forme conçue spécialement, comme un ordinateur central et des personnes ayant des compétences spécialisées que la plupart des entresockets n'ont pas en interne.

La plupart des personnes qui requestnt 99,999% de SLA sont pleins de merde, qv Microsoft, Accenture et London Stock Exchange .

Si l'argent est un problème, je proposerais fortement une autre solution de RDBMS.

RAC et DG sont très difficiles à configurer et à maintenir comme indiqué. Vous avez vraiment besoin de l'expertise pour le gérer. Vous avez besoin de SCAN, VIP, HB et HBA de preference.

En outre, je vous conseillerais fortement de restr loin de Windows pour Oracle.

Les données sur le SAN doivent également être RDM et pas un magasin de données.