Quelle est la meilleure architecture d'infrastructure SAP ERP?

Question

Mon entreprise envisage de mettre en œuvre SAP HR dans notre organisation. Nous avons déjà les autres modules en cours d'exécution. Nous prévoyons d'offrir ESS/MSS à environ 200 000 utilisateurs. Notre configuration actuelle est une machine avec une instance centrale et 3 machines avec des instances de dialogue. La base de données est sur la machine d'instance centrale. Enterprise Portal + DB s'exécute sur une machine distincte. Nous envisageons de séparer le module HR sur un DB séparé afin de ne pas tuer les autres modules avec load. Est-ce une préoccupation valable? Y a-t-il une meilleure façon d'architecturer le système? Je pensais à séparer les instances DB et Cental sur deux machines différentes. J'ai essayé de chercher sur le marché SAP n'importe quel conseil sur l'architecture d'infrastructure de SAP sans n'importe quelle chance.

Answer 1

Je ne suis pas tout à fait sûr de ce que l'on entend par « séparer le Nuevo » ...

je à travers l'idée de deux systèmes SAP seperat, un pour les RH et un (ou éventuellement d'autres multiples) pour le reste . Chacun de ces systèmes peut ensuite être dimensionné/sécurisé en fonction des différentes exigences (système HR de nombreux utilisateurs, utilisation peut-être élevée du dialogue, l'autre système peut être un peu plus "orienté batch"). Cela pourrait également être suggéré par la stratégie générale de SAP, chaque module faisant l'objet de son propre calendrier de diffusion. En ce qui concerne la DB et le serveur d'application (instance centrale?) Étant sur des machines différentes .. qui est en effet très commun et l'une des mesures les plus faciles d'accord. Vous pouvez mélanger et assortir "impitoyablement" avec le AppServer sur Solaris et la DB sur HP-UX.

Answer 2

1. La séparation de HR est une option valide. Ce n'est pas seulement la charge, mais aussi le module HR a des besoins de sécurité très strictes . Cela peut causer quelques difficultés dans la copie du système pour le système qa et le développement .
2. La séparation de l'instance centrale et du DB pour séparer les machines est une option valide. Mais je ne le ferais pas (Nous le faisons ...). Il cause une certaine complication dans le fonctionnement futur. Comme la mise à niveau et la maintenance de la base de données. Il est plus facile de retirer autant de charge de l'instance centrale. Supprimez-le simplement du groupe de connexion. Ainsi, seuls les processus de serveur de messages, de processus enque et de mise à jour (facultatif mais recommandé) sont conservés.

Mise à jour 1: Il n'est pas rare de séparer la base de données de l'instance centrale. Mais cela introduit une certaine complication. Cela, je pense, sont unnesesery.