Single-instance Implementations (2-tier or 3-tier)

By Ashwin Venugopal -

 

Overview

If you want go for a NetWeaver AnyDB deployment, then you can readily follow the standard (2-tier) or distributed (3-tier) NetWeaver installation options in SAP Software Provisioning Manager (SWPM). But, for the HANA-based ones, you will have to choose from one of the following methods:
  1. Use SAP Software Provisioning Manager (SWPM) as a part of the standard (2-tier) or distributed (3-tier) NetWeaver installation, followed by HANA installation.
  2. Use the SAP HANA database lifecycle manager (HDBLCM) tool, and then install NetWeaver.

The installation can start by an ASCS instance and the /sapmnt share, which have the SAP profile directory, should be shared with the SAP DB server VM. Depending on the OS of the DB server, the best way to provide access is via either SMB or NFS. 

The /sapmnt is shared via NFS while using Linux OS with the help of rw and no_root_squash options which may lead to problems while installing the database instance. Finally, the installation provisions the primary application server instance and after this is installed, you can easily use the tools like SAP GUI to verify that the installation finished correctly or not.

Key steps for SAP HANA installation when you use SAP SWPM

The following are the key steps for manual, single-instance SAP HANA installation when you use SAP SWPM to perform a distributed SAP NetWeaver 7.5 installation:
  1. Create an Azure virtual network.
  2. Deploy two Azure VMs with the help of Azure Resource Manager deployment model.
  3. Attach standard or premium data disks to the application server VM.
  4. Attach premium data disks to the HANA DB server VM.
  5. Create striped volumes using the attache disk. You can use either Logical Volume Management (LVM) or the multiple-devices administration (mdadm) tool inside the VM at the OS level.
  6. Create XFS file system on the attached disk or logical volumes.
  7. Mount the new volumes at the OS level by using separate volumes for the SAP binaries, /sapmnt directory, and backups. You should mount the XFS file systems on the premium storage disks as /hana and /usr/sap on the SAP HANA DB server which would prevent the filling up of root file system that isn't large on Linux AzureVMs.
  8. Add entries representing Azure VMs to the /etc/hosts file.
  9. Add the nofail parameter to the /etc/fstab file.
  10. Set Linux kernel parameters according to the Linux OS release you use.
  11. Add swap space.
  12. Optionally, install a graphical desktop on the test VMs or use a remote SAPinst installation.
  13. Download the SAP software from the SAP Service Marketplace.
  14. Install the SAP ASCS instance on the app server VM.
  15. Share the /sapmnt directory using  NFS whose server is the application server VM.
  16. Install the database instance by using SWPM on the DB server VM.
  17. Install the Primary Application Server (PAS) on the application server VM.
  18. Start SAP Management Console (SAP MC) and connect it with SAP GUI or HANA studio.  


Key steps for SAP HANA installation using HD-BLCM

The following are the key steps for manual, single-instance SAP HANA installation when you use SAP HDBLCM to perform a distributed SAP NetWeaver 7.5 installation:
  1. Create an Azure virtual network.
  2. Deploy two Azure VMs with the help of Azure Resource Manager deployment model.
  3. Attach standard or premium data disks to the application server VM.
  4. Attach premium data disks to the HANA DB server VM.
  5. Create striped volumes using the attache disk. You can use either Logical Volume Management (LVM) or the multiple-devices administration (mdadm) tool inside the VM at the OS level.
  6. Create XFS file system on the attached disk or logical volumes.
  7. Mount the new volumes at the OS level by using separate volumes for the SAP binaries, /sapmnt directory, and backups. You should mount the XFS file systems on the premium storage disks as /hana and /usr/sap on the SAP HANA DB server which would prevent the filling up of root file system that isn't large on Linux AzureVMs.
  8. Add entries representing Azure VMs to the /etc/hosts file.
  9. Add the nofail parameter to the /etc/fstab file.
  10. Set Linux kernel parameters according to the Linux OS release you use.
  11. Add swap space.
  12. Optionally, install a graphical desktop on the test VMs or use a remote SAPinst installation.
  13. Download the SAP software from the SAP Service Marketplace.
  14. Create a group, sapsys, with group ID 1001, on the HANA DB server VM.
  15. Install SAP HANA on the DB server VM with the help of HANA database lifecycle manager.
  16. Install the SAP ASCS instance on the app server VM.
  17. Share the /sapmnt directory using  NFS whose server is the application server VM.
  18. Install the database instance by using SWPM on the DB server VM.
  19. Install the Primary Application Server (PAS) on the application server VM.
  20. Start SAP Management Console (SAP MC) and connect it with SAP GUI or HANA studio.  

Implementing SAP HANA Scale-out

If you want to install a scale-out SAP HANA, you have to perform the following steps:
  1. Create new or use an existing Azure Vnet.
  2. Deploy VMs with managed Sremium storage disks.
  3. Deploy new or use an existing highly available NFS cluster.
  4. Validate that intra-node communication as well as traffic between the VMs and highly available NFS cluster is not routed through an NVA.    
  5. Install the SAP HANA master node according to the SAP's documentation.
  6. After the installation, you can add the parameter 'basepath_shared = no' to the global.ini file which allows SAP HANA to run in scale-out without 'shared' /hana/data and /hana/log volumes between the nodes.
  7. After changing the global.ini parameter, you can restart the SAP HANA instance.
  8. Add additional worker nodes.  

The scale-out configuration will use non-shared disks for running /hana/data and /hana/log while the /hana/shared volume will be placed on the highly available NFS share. 



Comments

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different groups of computers, re
Read more

Project Resourcing (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here Engineering - SIEM The SIEM engineers configures Microsoft Sentinel, including Log Analytics, Logic Apps, workbooks, and playbooks. They are also responsible for the following high-level tasks: Initial configuration of Azure tenant, including provisioning required resources, assigning access roles, and configuring workspace parameters like log retention, resource tagging, and blueprints.  Deployment and configuration of syslog/CEF log collection agents in appropriate locations to collect logs from on-premises devices. Generally, it will be joint effort of both system engineer and SIEM engineer, involving configuration and potential troubleshooting.  Working with system owners to enable log forwarding and configuring any required parsing of log data in Log Analytics.  Working with security operations to create and deploy KQL analytic rules to offer detections for SOC/Computer Security Incident Response Team (CSRIT) use. Tuning of alert rule parameter
Read more

Design Planning (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Complex Organizational Structures SIEM can be an expensive security control, hence, it is common multiple businesses to contribute to the overall expense. Various organizational units may require a level of access to specific dashboards or sets of data. Microsoft Sentinel offers the ability to assign table-level permissions and limit the level of access to the minimum required to perform requisite job functions.  Role-based Access Control (RBAC) Requirements Microsoft Sentinel offers an extensive list of Azure built-in roles that can be used to provide granular access according to the job requirements and permitted level of access. Some of them are various Microsoft Sentinel dedicated roles: Microsoft Sentinel Contributor- Can perform all engineering-related configuration, such as creating alert rules, configuring data connectors, and additional similar tasks.  Microsoft Sentinel Reader- Can query the log data stor
Read more