Or is it possible? Of course, the migration of SAP systems is a complex and painstaking process, for the success of which the coordinated work of all participants is important. And if the migration is carried out in a short time, the task becomes much more complicated. Not everyone is up for it. There may be several reasons. For example, the process itself is lengthy and organizationally complex. Plus, there is the risk of unplanned system downtime. Or clients are not sure that, having survived such an operation, they will receive benefits commensurate with the efforts spent. However, there are exceptions.
Under the cut, we will talk about the difficulties customers face in the process of migration and maintenance of SAP systems, discuss why stereotypes do not always correspond to reality, and share a case study on how we managed to migrate customer systems to a new infrastructure in just over three months.
Hosting of SAP systems
Just five years ago, it was hard to imagine that customers would massively start using hosting resources for SAP applications. In most cases, they were implemented on-premise. However, with the development of outsourcing models and the cloud services market, the mindset of customers has begun to change. What are the arguments influencing the choice in favor of the cloud for SAP?
- For beginners who have just planned the implementation of SAP, cloud infrastructure is almost a standard choice - the scalability of resources for the current needs of the system and the unwillingness to divert resources to the development of non-core competencies.
- In companies with a large system landscape, using SAP system hosting, CIOs reach a qualitatively different level of risk management. the partner is responsible for the SLA.
- The third of the most frequently encountered arguments is the high cost of building infrastructure to implement high availability and DR scenarios.
- Factor 2027 - the end of support for legacy systems announced by the vendor in 2027. This means moving the database to HANA, which entails the cost of upgrading and purchasing new computing power.
The SAP hosting market in Russia can now be considered quite mature. And this provides ample opportunities for customers who want to change their hosting platforms. However, such projects can rightly cause concern for businesses due to the complexity of the migration procedure. This forces customers to place increased demands on service providers, who must have not only exceptional competencies in hosting and maintaining SAP systems, but also successful experience in the field of migration.
What are the difficulties of changing SAP hosting?
Hosting is different. Inconsistency with the declared level of service, a lot of βbutsβ and asterisks with reservations in small text, limited resources and capabilities of the hosting provider, lack of flexibility in matters of communication with the client, bureaucracy, technical limitations, low competence of technical support specialists, and many other nuances - these are only a small part of the pitfalls that customers may encounter in the process of operating their business systems in outsourcing infrastructures. Often, for the client, all this remains in the shadows, in the wilds of a multi-page contract, and emerges already in the process of using the services.
At some point, it becomes obvious to the customer that the level of service he receives is far from his expectations. This is a kind of catalyst for finding solutions to correct the situation, and in case of failure, when problems accumulate to the limit and it becomes very painful, they proceed to active actions to develop alternative options in the direction of changing the service provider.
Why pull to the last? The reason is simple - the process of transferring systems for customers is not always transparent and understandable. It is difficult for the client to assess the actual risks associated with the migration process. We can say that migration for clients is a kind of black box: it is not clear, the price, system downtime, risks and how to level them, and in general it is dark and scary. Here, after all, if it doesnβt work out, then the heads will roll both among the tops and the performers.
SAP is an enterprise-level system, complex and, to put it mildly, not cheap. Decent budgets are spent on their implementation, refinement, maintenance, and the life of the enterprise depends on their availability and correct operation. Now imagine the consequences of stopping some major production. These are financial losses, which can be calculated in numbers with a large number of zeros, as well as reputational and other equally significant risks.
Let's analyze the difficulties that may arise at each of the stages on the case of migration of SAP systems of one of our customers.
Preparation and design
Migration is a formula with many different components. And one of the most important is the stage of designing and preparing the target (new) infrastructure.
We needed to dive into the existing implementation of systems, their architecture. In the target infrastructure, we repeated existing solutions somewhere, at some points supplemented and improved, somewhere they redesigned, thought over and chose solutions to ensure fault tolerance and availability, and also consolidated all resources to the maximum.
During the design process, many different exercises were performed, which ultimately made it possible to prepare for the migration as much as possible and take into account all sorts of nuances and pitfalls (more on them later).
What we ended up with is a custom-designed private cloud infrastructure based on our data center:
- dedicated physical servers for SAP HANA;
- VMware virtualization platform for application servers and infrastructure services;
- duplicated communication channels between data centers for L2 VPN;
- two main storage systems to separate the productive and "everything else";
- RMS based on Veritas Netbackup with a separate server, disk shelf and tape library.
And here is how they implemented all this from a technical point of view.
SAP
- To effectively use storage for productive HANA, we used shared disks without systemic database replication using SAP tools. All this was wrapped up in an Active-Standby SUSE HAE cluster based on Pacemaker. Yes, the recovery time is a little longer than with replication, but we get twice the savings in storage space and, as a result, save the customer's budget.
- In pre-production environments, HANA clusters were abandoned, but they technically repeated the production configuration.
- Test environments and development environments were smashed to several more servers without clusters in the MCOS configuration.
- All application servers were virtualized and hosted in VMware.
Networks
- We physically separated the contours of control networks and productive networks by stacks of switches, wrapping the productive ones in the direction of the customer's data center.
- We laid down a sufficient number of network interfaces so as not to mix large traffic flows.
- To transfer data from the storage system, they made classic FC SAN factories.
Storage
- The productive and pre-productive SAP load was left on the all-flash array.
- Developer test environments and infrastructure services were placed on a separate hybrid array.
IBS
- Made on the basis of Veritas Netbackup.
- Built-in scripts have been slightly added to backup MCOS configurations.
- We put the online copies on a disk shelf to recover quickly, and we use tapes for long-term storage.
Monitoring
- All hardware, OS and SAP were brought under Zabbix.
- We have collected many useful dashboards in Grafana.
- When an alert occurs, Zabbix can start a ticket in the incident management system, we have it implemented in Jira. Also, the information is duplicated in the Telegram channel.
Telegram
General state of HANA
SAP Application Server Status:
infrastructure services
- To serve internal namespaces, a cluster of DNS servers was raised, which is synchronized with the customer's servers.
- Made a separate file server for data exchange.
- To store various configurations, added Gitlab.
- For various Sensitive information, we took HashiCorp Vault.
Migration process
In general, the migration process consists of the following steps:
- preparation of all necessary project documentation;
- negotiations with the current provider - solving organizational issues;
- purchase, delivery and installation of new equipment for the project;
- test migration and process debugging;
- systems transfer, combat migration.
At the end of October 2019, we signed a contract, then we designed the architecture, and after it was agreed with the customer, we ordered the necessary equipment.
What you need to pay attention to first of all is the delivery time of the equipment. On average, the delivery of certified hardware for SAP NAHA, which meets the requirements of the software manufacturer for hardware platforms, takes 10-12 weeks. And taking into account seasonality (the implementation of the project fell exactly on the new year), this period could increase by another month. Accordingly, it was necessary to speed up the process as much as possible: we worked with a distributor-supplier, agreed on expedited delivery by air (instead of land and sea routes).
November and December were spent preparing for the migration and getting some of the equipment. We conducted the preparation on a test bench in our public cloud, where we worked out all the main steps and caught possible difficulties and problems:
- prepared a detailed plan for the interaction of project team members with per-minute timings;
- built a test bench for the database and application servers in much the same way as in the target infrastructure;
- set up the necessary communication channels and infrastructure services to test the integrations;
- worked out cutover scenarios;
- the cloud also helped us generate pre-configured VM templates, which we then simply imported and deployed to the target landscape.
Shortly before the New Year holidays, the first batch of equipment arrived to us. This made it possible to deploy part of the systems on real hardware. Since far from everyone arrived, we connected replacement equipment, the supply of which we managed to agree with the vendor and distributors. We received the remains of the target infrastructure already at the final stage.
In order to meet the deadline, our engineers had to sacrifice the New Year holidays and start work on preparing the target infrastructure on January 2, in the midst of the holidays. Yes, this sometimes happens when it burns and there are simply no other options. At stake was the performance of systems on which the life of the enterprise depends.
The general order of migration looked like this: first of all, the least critical systems (development landscape, testing landscape), then productive systems. The final stage of migration took place in late January-early February.
The migration process was scheduled to the minute. This is a cutover plan with a list of all tasks, due dates and responsible persons. All the steps have already been worked out on a test migration, so in a live migration, it was just necessary to follow the plan and coordinate the process.
Migration was carried out system-by-system in several stages. Each stage has two systems.
The result of the three-month sprint was a system that is fully functional in the CROC DPC. In general, a positive result was obtained thanks to the joint work, the contribution and dedication of all participants in the process was maximum.
The role of the customer in the project
It was not easy to communicate with the provider that our client was leaving. It is understandable, they were the last in the list of persons interested in the successful completion of the project. The customer took on the task of escalating and pedaling all communication issues and coped with this by 100500%. Special thanks to him for this. Without such a feasible participation in the process, the result of the project could have been completely different.
Due to the formalization of the processes on the side of the "former" provider, the infrastructure was supported by specialists who were literally far from the problems, at that time still their customer. For example, the process of exporting the same database could take from one to five hours. Then it seemed that it was some kind of magic, a secret that was never revealed to us. Probably technical support engineers indulged in meditation in between, forgetting that somewhere in distant Russia there are deadlines, engineers without New Year's salads, the customer is crying and suffering ...
Results of the project
The final chord of the migration was the transfer of systems for maintenance.
Now we provide a one-stop service for customer requests and close the entire scope of tasks for maintaining infrastructure components and SAP basis together with a partner - itelligence. The client has been living in a private cloud for six months. Here are the statistics on service cases during this time:
- 90 incidents (20% resolved without customer involvement)
- Solved within SLA β 100%
- Unscheduled system shutdowns - 0
If you have tasks similar to those of our client, and you want to learn more about how to solve them, write to: [email protected]
Source: habr.com