Deploying an SL1 Virtual Machine in Azure

This section describes how to deploy a ScienceLogic virtual machine in Azure from a VHD image file.

To deploy an SL1 appliance in Azure, you need the following components:

• Windows PowerShell version 5 or later
• PowerShellGet and Azure RM modules installed
• Azure CLI tool
• An Azure Resource group
• An Azure storage account that includes at least one blob container
• An Azure Network Security Group (NSG)

Use the following menu options to navigate the SL1 user interface:

• To view a pop-out list of menu options, click the menu icon ().
• To view a page containing all the menu options, click the Advanced menu icon ().

The steps to create these components in Azure are described throughout this section. This section includes the following topics:

NOTE: If you are configuring a Database, ScienceLogic recommends allocating four times the memory for the Database as compared to the memory for the Data Collectors.

TIP: A single Azure image file can be used to create multiple virtual machines. For example, you can use the same Azure VHD file for the Database Server to create multiple Database Servers.

System Requirements

For details about supported hypervisors and the requirements and specifications for each SL1 appliance, see the ScienceLogic Support Site: https://support.sciencelogic.com/s/system-requirements

Deploying an SL1 System in Azure

This section provides the information you need to deploy SL1 in Azure and includes procedures for each step.

SL1 Appliance Deployment Order for Distributed Systems

To deploy a distributed SL1 system on Azure instances, create appliances in this order:

1. Database Server
2. Administration Portal (if applicable)
3. Data Collectors
4. Message Collectors (if applicable)

Installing and Configuring the Azure CLI

Azure CLI is a tool that lets you manage resources in Azure. To complete the SL1 installation on Azure using the procedures in this section, you must have the Azure CLI tool installed.

To install and configure the Azure CLI tool:

1. Download and install the Azure CLI tool from the Microsoft website:

   https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-windows?view=azure-cli-latest

2. After installation completes, search for and click on "PowerShell" in Windows to start the program.
3. In PowerShell, type "az login". You will be prompted to sign into your Microsoft Azure account.

   After you log in, you will see information about your Azure subscription within the PowerShell window.

Configuring an Azure Resource Group and Storage Account

To create and configure an Azure storage account:

1. Log in to the Azure Portal, and then click Resource groups on the left menu.

2. Click the Add button and add information for a new Resource group. Click the Create resource group button to create the Resource group.
3. After creating the Resource group, click Storage accounts on the left menu.

4. Click the Add button, and then click the Create Storage accounts button to create a new Storage account. When creating the Storage account, complete the following fields:

• Deployment model. Select Resource manager.

• Account kind. Select General purpose.
• Resource group. Select Use existing, and then select the Resource group you created in step 2.

5. After creating the Storage account, click Storage accounts on the left menu, and then select the newly created Storage account.
6. Under the Services section of the Storage account pane, click Blobs. The Blob service blade information appears.

7. In the Blob service pane, click the Plus icon to add a new container. Type a name for the container and select Blob as the Access Type. When you are finished, click the Create button to create the Blob container.

Obtaining the Container URL for an Azure Storage Account and Creating the BLOB_URI

Before you can upload the VHD image file, you will need to determine the BLOB_URI value from your Azure storage account. The container URL, along with the VHD filename you append, is used for the BLOB_URI value you will use when you upload the VHD file. This BLOB_URI tells Azure where to put the VHD file and what to call it.

To get the container URL:

1. Log in to the Azure portal.
2. Select Storage Accounts.
3. Select the Containers section.
4. Click the ellipsis (...) button to the right of the container name to open the pop-up menu.
5. Click Container Properties in the pop-up menu. You will see a URL displayed in the Properties.
6. Click the blue Copy icon on the Properties page to copy the URL for the container.

To create the BLOB_URI value, append the destination (that is, where you want the VHD to be stored in the container) to the container URL.

Example:

If the container URL is:

https://azuretest.blob.core.windows.net

 

Your BLOB_URI value might be:

https://azuretest.blob.core.windows.net/vhds/em7inazure.vhd

 

Where "/vhds" is the directory on the container, and "em7inazure.vhd" is the name of the VHD image file you will be uploading.

Uploading a VHD Image File to an Azure Storage Account

After creating the Resource group, Storage account, and Blob container, you must upload the ScienceLogic VHD image file to the Blob container. To do so, you will need the following information:

• The ScienceLogic VHD file
• Resource Group name
• Blob container URI
• Local file path to the VHD file

Downloading the ScienceLogic VHD File

To download the ScienceLogic VHD file:

1. Open a browser session and go to:

support.sciencelogic.com

 

2. Go to the Product Downloads menu and choose Platform.
3. Find the platform version that you want to download. Click on its name.
4. Expand the Release Files list and find an entry of Record Type Product Image.
5. In the Release File Downloads pane to the right, download the .vhd files for each SL1 appliance.

Uploading the VHD File to an Azure Container

To upload the ScienceLogic VHD file to your Blob container, perform the following steps:

1. Open Microsoft Azure PowerShell and log in to your Azure account using the cmdlet Add-AzureRmAccount:

Login-AzureRmAccount

 

2. You created a resource group and storage container blob to which you will upload your VHD image file in Configuring an Azure Resource Group and Storage Account. You identified the BLOB_URI in Obtaining the Container URL for an Azure Storage Account. Now you are ready to upload your VHD image file.

The virtual machine that you create in Creating an Azure Virtual Machine must be in the same resource group as the storage account.

3. Add your VHD file to the storage account with the following cmdlet:

Add-AzureRmVhd -Destination '<BLOB_URI>' -LocalFilePath '<VHD_LOCAL_FILE_PATH>' -ResourceGroupName '<RESOURCE_GROUP>'

 

Where:

• BLOB_URI specifies the BLOB_URI where you will upload your VHD file.
• VHD_LOCAL_FILE_PATH specifies the path on your machine for the VHD file you want to upload
• RESOURCE_GROUP specifies the resource group you created and that will be used when you create the Azure VM.

4. Repeat step 3 for each VHD file.

Creating the Disk Image

The following steps require that you have an ARM resource group and storage account with the VHD file uploaded.

To create the disk image:

1. Open Microsoft Azure PowerShell and log in to your Azure account using the cmdlet Add-AzureRmAccount:

Login-AzureRmAccount

2. Run the following command:

az disk create -g <resource-group-name> -n <disk-name> --source <BLOB_URI>

 

Where:

• resource-group-name specifies the resource group you created in Azure.
• disk-name specifies what you want to call the disk (such as "dbdisk123").
• BLOB_URI specifies the destination value you provided when you uploaded the VHD file. This is also the BLOB_URI you created in Obtaining the Container URL for an Azure Storage Account.

Creating an Azure Virtual Machine

The following steps require that you have an ARM resource group and storage account with the VHD file uploaded.

To create an Azure virtual machine:

1. Open Microsoft Azure PowerShell and log in to your Azure account using the cmdlet Add-AzureRmAccount:

Login-AzureRmAccount

 

2. Run the following command:

The virtual machine that you create must be in the same resource group as the storage account.

az vm create -g <resource_group_name> -n <VM_name> --os-type linux --attach-os-disk <disk_name> --vnet-name <virtual_network_name> --subnet <subnet_name> --size <VM_type>

 

Where:

• resource_group_name specifies the resource group you created in Azure.
• VM_name specifies what you want to call your VM.
• disk_name specifies the name you gave to the disk when you created it.
• virtual_network_name specifies the virtual network name you want to use within Azure.
• subnet_name specifies the subnet name you want to use within Azure.
• VM_type specifies the Azure VM type you want to use, such as "Standard_DS2_VS". You can find a list of Azure machine types and attributes here: https://docs.microsoft.com/en-us/azure/virtual-machines/sizes-general

Setting the Virtual Machine Allocation Method to Static

To ensure the IP address for the virtual machine remains the same after reboot, you must set the allocation method to static. To do so:

1. In the Azure Portal, navigate to the Virtual machine pane and verify that the virtual machine has a public IP address and a virtual network/subnet set.

2. Click the name of the Virtual network/subnet. The Virtual network pane appears.

3. In the “Connected devices” section of the Virtual network pane, click the Network interface. The Network interface pane appears.

4. Click the Public IP address value, and then click the Dissociate button.

5. In the Network interface pane, click on Settings > IP addresses. Then, do one of the following:

• If you are not using a VPN, complete steps 6 through 9. Ignore step 10.
• If you are using a VPN, skip ahead to step 10.

6. If you are not using a VPN, then in the IP addresses pane, select Enabled in the Public IP address field and then click on the IP address field.
7. Click the Create new button.
8. In the Create public IP address pane, type a name for your IP address in the Name field and select Static in the Assignment field.
9. Click OK and then click Save.
10. If you are using a VPN, then in the IP addresses pane, select Disabled in the Public IP address field and then select a Subnet. You can use the default values for all other fields.

Configuring Ports on SL1 Appliances

You must next create a Network security group that will specify the ports required for communication between the SL1 appliances and that will specify the ports required for communication between the SL1 appliances and the monitored devices in your network.

To configure the ports for communication:

1. In the Azure Portal, navigate to the Network security groups pane, and then click the Add button. The Create network security group pane appears.

2. Type the information for the Network security group (name, subscription, resource group, and location), then click Create.
3. In the Network security groups pane, click the newly created Network security group, and then click the Settings button.
4. In the Settings pane, click Inbound security rules.

5. In the Inbound security rules pane, click the Add button. The Add inbound security rule pane appears.

6. Use the table below to create security rules.
7. Repeat steps 5 and 6 to create an inbound security rule for each of the ports listed in the table below.
8. After creating all of the inbound security rules, navigate to the Virtual machine pane and click the Settings button.
9. In the Settings pane, click Network interfaces and then click on the name of the Network interface.
10. In the Network interface pane, click the Settings button and then click Network security group.
11. Select the newly created network security group to associate it with the Network interface.
12. Perform steps 9-11 for each network interface in your SL1 system.

ScienceLogic recommends that you limit the Source port range for security reasons.

Type	Protocol	Port	Description
SSH	TCP	22	SSH. This is necessary to start the installation wizard.
SMTP	TCP	25	Necessary to receive inbound email for tickets, events, and email round-trip monitoring.
HTTP	TCP	80	HTTP from browser session or user workstation.
Custom TCP Rule	TCP	123	NTP. Communication between the All-In-One Appliance and configured NTP server.
Custom UDP Rule	UDP	161	SNMP Agent. Allows SNMP information about the SL1 appliance to be collected by SL1.
Custom UDP Rule	UDP	162	SNMP Traps. Necessary to receive SNMP traps from managed devices.
HTTPS	TCP	443	HTTPS from browser session or user workstation.
Custom UDP Rule	UDP	514	Syslog messages. Necessary to receive syslog messages from managed devices.
Custom TCP Rule	TCP	7700	ScienceLogic Web Configurator. Configuration Utility from browser session or user workstation. This is necessary to license the appliance.
Custom TCP Rule	TCP	7705	ScienceLogic PhoneHome. See Configuring SL1 for PhoneHome Communications.
Custom TCP Rule	TCP	7706	MySQL. Communication from Administration Portal.
Custom TCP Rule	TCP	7707	Data Pull. Allows the Database Server to retrieve data from the SL1 appliance.
Custom TCP Rule	TCP	8008	Administrative Web Interface (PHPMyAdmin) from browser session on user workstation.

Configuring the Virtual Machine

To configure each virtual machine, perform the following steps:

1. Use SSH to access the virtual machine using its public IP address and the username and password that were defined in step 2 of the section Creating an Azure Virtual Machine.

2. Run em7_install.sh in a special operational mode:

   sudo /opt/em7/share/scripts/em7_install.sh --instance-init-only

3. On the Administration Portal (and the Database Server only if you are using the Administration Portal on the Database Server), run the following command to start the web server:

   sudo service nginx start

4. Using vi or another text editor, edit the /etc/silo.conf file.

   sudo visilo

5. In the LOCAL section, set ipaddress to the Azure virtual machine's public IP address. If a VPN is used, however, set the ipaddress field to the VM’s private IP address. For example, see the bolded text below:

   [LOCAL]
   rootdir = /opt/em7
   vardir = /var/lib/em7
   logdir = /var/log/em7
   rundir = /run/em7
   ipaddress = 172.16.10.10
   dbdir = /data/db
   dbserver = 172.16.10.11
   dbport = 7706
   dbuser = root
   dbpasswd = em7admin
   portcheck = /usr/bin/nmap
   model_type = 1
   eventmanager = internal,email,syslog,trap,dynamic

6. Perform the required steps in the Web Configuration Tool.

• For instances of the Database Server or All-In-One Appliance:

• Licensing the instance in the Web Configuration Tool

Upon installation, SL1 appliances are automatically licensed for 30 days. During these 30 days, you can perform the steps to obtain a permanent license from ScienceLogic.

• For instances of the Administration Portal:

• Configuring the instance in the Web Configuration Tool
• When prompted for the IP address of the Database Server,

• If you are not using a VPN, enter the public IP address of the Database Server.
• If you are using a VPN, use the private IP address of the Database Server.

• For instances of the Data Collector and Message Collector:

• Configuring the instance in the Web Configuration Tool
• When prompted for the IP address of the Database Server,

• If you are not using a VPN, enter the public IP address of the Database Server.
• If you are using a VPN, use the private IP address of the Database Server. .

7. Open a browser session to SL1 (to the Administration Portal). Go to the Appliance Manager page (System > Settings > Appliances).
8. If you are using an All-In-One Appliance, you will see two entries for the All-In-One Appliance.

• Select the bomb icon for the All-In-One Appliance for which the bomb icon () is enabled.
• In the remaining entry, select the wrench icon (). In the top pane, enter the IP Address specified in Azure for the All-In-One Appliance. Click Save.

9. If you are using a distributed system, you will see two entries for the Database Server.

• Select the bomb icon for the Database Server for which the bomb icon () is enabled.

Additional Steps for SL1 10.1

SL1 10.1.x includes an upgrade to MariaDB. The upgrade did not include a tool, jemalloc, that helps manage memory usage.

To avoid problems with memory usage on Database Servers, perform the following steps after upgrading MariaDB for 10.1.x.

Perform these steps first on the active Database Server and then on each additional Database Server in your SL1 System.

1. Open an SSH session to the Database Server.

2. To verify that the Database Server is not currently running jemalloc, enter the following command at the shell prompt:

   silo_mysql -e 'show global variables like "version_malloc_library"'

If the Database Server is not currently running jemalloc, the shell will display the following:

Variable Name	Value
version_malloc_library	system

3. Search for the file /usr/lib64/libjemalloc.so.1.

   If the file does not exist, contact ScienceLogic Customer Support to request the file jemalloc-3.6.0-1.el7.x86_64.rpm.

   To install the RPM, use a file-transfer utility, copy the file to a directory on the SL1 appliance. Then enter the following commands at the shell prompt:

   cd /usr/lib64
   sudo yum install jemalloc-3.6.0-1.el7.x86_64.rpm

4. Create the file /etc/systemd/system/mariadb.service.d/jemalloc.conf, as follows:

   vi /etc/systemd/system/mariadb.service.d/jemalloc.conf

5. Add the following lines to the file:

   [Service]
   Environment="LD_PRELOAD=/usr/lib64/libjemalloc.so.1"

6. Save and close the file.

7. Reload the systemd config files with the following command:

   sudo systemctl daemon-reload

8. Restart the Database Server:

   To restart the standalone Database Server or the primary Database Server in a cluster, enter the following:

   sudo systemctl restart mariadb

   To restart each secondary Database Server in a cluster:

1. Open an SSH session to the secondary Database Server. At the shell prompt, enter:

   coro_config

2. Select 1.
3. When prompted to put the Database Server into maintenance, select y.

4. Open an SSH session to the primary Database Server. To pause SL1, enter the following command at the shell prompt:

   sudo touch /etc/.proc_mgr_pause

5. In the SSH session for the secondary Database Server, restart MariaDB:

   crm resource restart mysql

6. After MariaDB has restarted successfully on the secondary Database Server, return to the SSH session on the primary Database Server. Remove the pause file for SL1 using the following command:

   sudo rm /etc/.proc_mgr_pause

7. In the SSH session on the secondary Database Server, take the Database Server out of maintenance. At the shell prompt, enter:

   coro_config

8. Select 1.
9. When prompted to take the Database Server out of maintenance, select y.

9. To verify that jemalloc is running on the Database Server, enter the following command at the shell prompt:

   silo_mysql -e 'show global variables like "version_malloc_library"'

If the Database Server is currently running jemalloc, the shell will display something like the following:

Variable Name	Value
version_malloc_library	jemalloc 3.6.0-0-g46c0af68bd248b04df75e4f92d5fb804c3d75340

10. Perform these steps on each Database Server in your SL1 system.

Troubleshooting

If the Data Collector continuously displays a message saying the collector is working when running a Dynamic Application, DO NOT restart the Azure virtual machine, as doing so could cause you to lose SSH access to the machine.

Instead, do the following:

1. Using the command line interface, verify whether you can run the Dynamic Application in debug mode by typing the following command:

sudo /usr/local/silo/proc/dynamic_single.py <did> <app_id>

 

2. Restart the data pull processes (em7_hfpulld, em7_lfpulld, em7_mfpulld) by typing the following command:

sudo service <service_name> restart