This blog contains experience gained over the years of implementing (and de-implementing) large scale IT applications/software.

HowTo: Find the Datacentre Region and Physical Host of your Azure Windows VM

With VMs hosted in Azure you need a fine balance between protection from hardware failure on the underlying Azure platform, plus performance from having the tiers of your SAP application being physically close together.

For this very purpose, Microsoft introduced Proximity Placement Groups (PPGs) to allow an administrator to ensure that specific tiers (e.g. application and database) are located close. Potentially even in the same server rack.
The PPGs also affect the location of the storage assigned to the VMs, although the storage infrastructure is actually transparent to administrators.

The PPGs still allow Azure to honor the Availability Sets, Fault Domains and Update Domains.

In this post, I show a method of finding the physical hostname of your Windows VM which could be part of a check before/after implementing a PPG.
NOTE: PPGs should be created at the time a VM is created, and assigned to the “lead” system of the rarest size. Example, an M-series VM is rare, so this should be the lead system when creating the PPG. This will anchor the other VMs to this M-series VMs location.

The previous blog post shows how to do this for a Linux VM.
On a Windows VM in Azure, as any Windows user with access to the registry, you can use the following to see the name of the physical host on which your VM is running:

reg query "HKEY_LOCAL_MACHINE/Software/Microsoft/Virtual Machine/Guest/Parameters" /v PhysicalHostName

Example output:
PhysicalHostName    REG_SZ      DUB012345678910

Example with “AMS” prefix (Amsterdam)

In this case, we take the first 3 chars to be “Dublin”, which is in the EU North Azure region.
The remaining characters consist of the rack and physical hostname.

If you have 2 VMs in the same rack on the same physical host, then you will have minimal latency for networking between them.
Conversely, if you have 2 VMs on the same physical host, you are open to HA issues.

Therefore, for SAP, you need a good balance of distance.

You should expect to see SAP S/4HANA application servers and HANA DBs placed in the same Proximity Placement Groups, within the same rack, even potentially on the same host (providing you have availability sets across the tiers you will be safe).

Starting and Stopping Individual SAP AS Java Server Processes

Should you need to restart either manually or automatically (via script) a specific AS Java server node, it’s possible to use the sapcontrol tool to provide precise control.

The method detailed below is based on the documentation provided here:
Performs a given control function (EnableProcess/StartProcess, DisableProcess/StopProcess,
SoftStopProcess, ActivateProcess, DeactivateProcess, RestartProcess, SoftRestartProcess,
DumpStackTrace, EnableDebugging, DisableDebugging, IncrementTrace, DecrementTrace) on a given AS
Java process. processname must match a process name in the AS Java process list returned by
J2EEGetProcessList. To perform AS Java instance-wide operations (StartInstance, StopInstance,
RestartInstance, BootInstance, RebootInstance), use processname “all”.
Based on the above information, we can query the AS Java processes for a specific AS Java instance, using the following command line as the sidadm user:

sidadm> sapcontrol -host [host] -nr [sys##] -function J2EEGetProcessList
You should substitute the “host” and “sys##” with the host of your application server (virtual host) and the SAP instance number.
The command will return a list of the processes that the instance is running.
For a 2 node AS Java system, you can see the Server0 and Server1 processes in the list.
To restart Server0 on the AS Java instance use the below command line as the sidadm user:

sidadm> sapcontrol -host [host] -nr [sys##] -function J2EEControlProcess “server0” “RestartProcess”
You should substitute the “host” and “sys##” with the host of your application server (virtual host) and the SAP instance number.
Change “server0” for “server1” if you want to restart server1.
Based on the above restart, you can monitor the restart by using the below command line to see when the restart is completed:
sidadm> sapcontrol -host [host] -nr [sys##] -function J2EEGetProcessList | awk -F, ‘{ if ( $2 != “” && FNR > 5 ){ print “Name: “$2″ttState: “$8″ttStarted: “$9 }}’
You should substitute the “host” and “sys##” with the host of your application server (virtual host) and the SAP instance number.

SAP HANA – Migrate Statistics Server 1917938

Since SAP note “1917938 – Migration of statistics server with upgrade to SPS 7” seems to be going missing rather a lot, I’ve noted the content here for reference based on v10 05-05-2014.

If you do not monitor or administrate the upgraded SAP HANA database with the DBA Cockpit or Solution Manager, you can activate the new statistics server. If the DBA Cockpit or Solution Manager is active, you are only allowed to activate the new statistics server if you observe SAP Note 1925684.

A configuration change is required to activate the new statistics server:

nameserver.ini -> [statisticsserver]->active=true

The data held in the persistence of the statistics server is now transferred to the persistence of the master index server. At the end of the migration, the statistics server is automatically stopped and removed from the database configuration (topology). The functions of the statistics server are distributed to other services.

The migration of the statistics server is carried out without interrupting the backup history, which means that data and log backups created before the migration can still be used to restore the SAP HANA database.

The HANA instance must not be restarted during the migration.
The migration is completed when no statisticsserver process is running in the HANA instance.
It is not necessary to restart the HANA instance following the migration.