Components

This topic describes the Component tab interface of the System Console.

As the name indicates, the Components tab displays a list of all the Platform logical components for the administrator to view the load of each component and make suitable decisions around load-balancing.

Access the Components tab from the Application Switcher > System Console > System.

From this page, you can:

  • View the current status of all servers, including information about the component type, its properties, stats such as number of customers loaded on the servers, number of sessions, host name, the duration and running jobs.

  • View the current status of all production servers, all databases.

  • Refresh the components list to view updated information for all the components.

  • Edit the display name of a component.

  • Click a Platform component name to view its information in the Component Information page. This page displays component information such as the component, its name, type, power, external URL including current status such as the instances and instance details, customer load details, currently logged-in user(s) details, and a list of currently running job(s) (i.e., import, batch, and customer creation jobs) details.

    • A component power is a decimal number between 0.5 to 2.0 indicating the relative computational power of production server. A server with higher power gets a higher load.

The Components page also displays active BACKUP components. A BACKUP component processes system backup and system restore jobs for customers assigned to the BACKUP processing route.

Running Jobs

The Running Jobs table displays the list of running jobs for the selected component such as master, prod, and storage servers.

Resiliency of jobs represents the ability of jobs to recover from node failures or other external conditions. Nodes pick up a job for execution without stepping on each other from a common database store. It is guaranteed that a given job will be executed only once by a pool of nodes. Platform supports multiple job pools for a customer/tenant which are as follows:

  • Delayed Trigger jobs

  • Batch jobs

  • Import jobs

  • Large jobs

  • Mail jobs

Note: For a customer, only 1 job from each pool is executed in parallel. Not more than 1 job from the same pool is executed.

When a node is down, all jobs move from running status into a waiting status. The idea is to ensure that in case of an error, a job is eventually executed. Import jobs and MassRun jobs support progress tracking when a node fails and another node picks it up. All other job types are restarted and executed from the beginning.

All jobs that are in a waiting state can be cancelled. The following jobs can also be cancelled when they are in the running state:

  • Data Maintenance

  • MassRun

  • SfdcImport

  • MoveStorage

  • SystemBackup

  • SystemRestore

  • Import

  • Mass Update

Note: Any batch job in waiting status can be cancelled from the System Console > Monitoring > Jobs > Action. However, only the above mentioned jobs can be cancelled in the running state as well. See Monitoring for more information.
Example: Cancelling an Import job. Consider an Import job that involves importing 1000 records wherein, 480 records have already been imported and 520 records are pending import. At this point, if this import job is cancelled, the cancel operation impacts the remaining 520 records pending import. However, for the 480 records that were already imported, Platform sends an email notification to the customer/user.
As a best practice, always consider the impact of the cancel operation on a job when it is in running state. For example, certain job types such as SystemRestore should be cancelled understanding the fact that it may render the tenant in an unsuable state.

For a BACKUP component, the Component Information page displays the system backup and restore jobs currently owned by that component. Platform maintains customer-level serialization for these jobs. Only one system backup or restore job for the same customer is processed at a time within the selected processing route.

Users can monitor backup and restore operations from the Running Jobs section. The following are examples of the stages involved in a backup or restore job.

  • For backup:

    System Backup [Preparing execution paths]
    System Backup [Generating database artifacts]
    System Backup [Backing up customer tables] [Table 7/71: RB_USER, rows 400]
    System Backup [Creating final archive]
    System Backup [Syncing backup directories to cloud] [Directory 2/3: data]

  • For restore:

    System Restore [Reading backup metadata]
    System Restore [Restoring customer tables] [Table 12/71: RB_USER]
    System Restore [Restoring directory data] [Directory 1/3: images]
    System Restore [Restoring published app artifacts]
    System Restore [Finalising restore]