Deployment FAQs

How to cast the Oculus GO?

Oculus recently announced that they are enabling casting options for the Go.

This came as great news to creators globally so you are not disconnected from the users when wearing the headset.

Here's how you can set this up:

There are a few legacy methods that you can still fall back on, you can find them here.

How to handling authentication?

Published GMETRI content has to be authenticated in several cases, and you may need to control access to your experiences especially for internal experiences.

There are a couple of ways to achieve this.

You Handle the Authentication

  • Embed the experience on their App/Website/etc. and keep the access to this page authenticated.
  • You can enable a text field at the beginning of the experience, asking users to input their unique identifier (Example. Employee ID for internal training) so you can reference that back to the analytics, if required.
  • This method will incur no additional charges from GMETRI. (Analytics charges, of course, are extra, and optional.)

We Handle the Authentication

  • You can create as many GMETRI view-only accounts for a project as required.
  • Example: A GMETRI view-only account can be provided to each trainee for a VR training module.
  • In this case, the authentication prompt will require credentials that have to be defined by the user during the first login.
  • This is a chargeable feature, and the pricing depends on the number of view-only accounts created.

What are the kind of insights I can get using Custom Dashboards?

The GMetri platforms can store the following data points for any viewer of the immersive experiences:

  • What the user looks at / interacts with - including coordinates of the user(s)
  • When: The amount of time spent on the whole experience, per scene or looking at a single element
  • How the user interacts with his/her surroundings - including what buttons were clicked/ what actions were performed on which element(s)/scene(s), and tracking user score in quizzes

The above-captured metrics can be combined in various ways to get may insights through Custom Dashboard. These insights may include:

  • User Performace/Leaderboard - by combining the total score of the user with the time spent by the user in the experience, one can estimate how well the user may perform in a real-world scenario.
  • Creating domain-specific dashboards focusing on a few aspects of the training to gain further insights. Eg: measuring how one handles corrective situations in client interactions, or measuring how well versed a user is with technical processes, compliance, safety, soft-skills, etc.
  • Dashboard to focus on user time spent, to create a feedback loop to detect and fix problems in the immersive environment itself - for example, if a user doesn't spend enough time at a particular section vs. other sections, it could have something to do with the design of the scene or the storyboarding. This information can then feed into the correction of the scene/storyboard itself, and to and any improvements may be measured over time.

Can I deploy GMetri Enterprise Services in my private cloud (firewalled zone)?

GMetri services, if required, can be deployed safely in your private cloud (firewalled zone). The preferred mode of a private cloud deployment is through Kubernetes and helm charts.

By using a single helm command you can deploy GMetri services on your private cloud and also keep it updated.

The Hardware requirements for the same are listed here.

Feel free to contact us for further details!

Which network ports needs to open for a private cloud deployment?

This is in continuation of the Private Cloud Deployment Guide.

Ideally, within the cluster, communication needs to be open - i.e. all cluster nodes should be able to contact all ports of all other cluster nodes.

However in case a list of open ports is required, you can use the following list:

Description Within Cluster (In AND Out) External Load Balancer (In) Internet (Out)
Kubernetes Specific 22 TCP
80 TCP
443 TCP
2376 TCP
2379 TCP
2380 TCP
6443 TCP
6783 TCP
6783-6784 UDP
8472 UDP
9099 TCP
10250 TCP
10254 TCP
80 TCP 443 TCP git.rancher.io:
35.160.43.145:32
35.167.242.46:32
52.33.59.17:32

*.gmetri.com
*.gmetri.io
*.vrgmetri.com
*.docker.io
Workload Specific 30000-32767 TCP & UDP
Project Specific 3000-3100 TCP
3306 TCP
5432 TCP
6739 TCP

We ideally recommend that GMetri is deployed on a cluster setup in a private cloud consisting of a minimum of 3 servers. However, in cases where that is not possible, GMetri can also be deployed on a single rack-server or a desktop.

The following are the recommended hardware requirements for such a deployment:

Hardware Specification Example
CPU A 4-core/8-thread processor Intel i7-7700K
RAM 32 GB DDR-4 Corsair LPX 32GB (2x16GB) 3200MHz
HDD 256 GB SSD or SAS storage Samsung 860 EVO 250GB SSD
LAN Ports A single LAN port is enough (Part of the server/desktop)

Keep in mind that this is not a HA (High Availability) setup. This means that any hardware failure could lead to permanent loss of data. In cases where data resiliency is critical, we recommend a cluster setup.

Architecture

The GMETRI platform deploys as helm charts on Kubernetes clusters. A working Kubernetes cluster is needed (either On-Cloud like AWS/Others or in your private cloud) before a helm chart can be deployed. On a Kubernetes cluster, by using a single helm command you can deploy GMetri services on your private cloud and also keep it updated.

Below are the hardware and network requirements to set up a Kubernetes cluster in a private cloud that supports the GMetri platform.

The steps to install helm charts are deployment specific and detailed in a separate guide.

Hardware Requirements

The following table lists the minimum requirements setting up a High Availability (HA) cluster:

On Cloud (AWS/Others)

Spec Production Values Development Values
Recommended Node Type AWS: m4.large/m5.large
GC: n1-standard-2
Azure: D2s v3
AWS: m4.large/m5.large
GC: n1-standard-2
Azure: D2s v3
Nodes (Virtual Machines) with vCPUs >2Ghz 3 (etcd + control plane) + 3 worker nodes
Minimum 6 nodes (Virtual Machines, across availability zones)
Min requirement for each node:
2 core vCPU + 8 GB RAM
3 (etcd + controlplane + worker) nodes
Minimum 3 nodes (Virtual Machines, across availability zones)
Min requirement for each node:
2 core vCPU + 8 GB RAM
RAM 8 GB × number of nodes 8 GB × number of nodes
Storage (SSD Based or better) Min 256 GB per node supporting >500 sequential IOPS Min 128 GB per node

Bare Metal (HA Setup)

Spec Production Values Development Values
Servers with every core >2Ghz 3 (etcd + control plane) + 3 worker nodes
Minimum 6 servers on at-least 3 different physical machines (in case the servers are VMs)
Min requirement for each node:
2 core vCPU + 8 GB RAM
3 (etcd + controlplane + worker) nodes
Minimum 3 servers
Min requirement for each server:
2 core vCPU + 8 GB RAM
RAM 8 GB × number of nodes 8 GB × number of nodes
Storage (SSD Based or better) Min 256 GB per node supporting >500 sequential IOPS Min 128 GB per node
  • Full network connectivity between all systems in the cluster
  • Ability to configure open ports on these systems
  • Failure resilience for production servers: 1 for master nodes and 1 for worker nodes separately. The resilience is of (n-1)/2 nodes per node-type where n is the number of nodes.

Operating System Requirements

The Operating System used will depend completely on the flavour of Kubernetes deployed. Examples are RancherOS, Ubuntu, CoreOS etc.

Preferred OS

For Cloud deployment: Ubuntu 18+

For Bare Metal deployment: CentOS 7.4+ or Ubuntu 16.04+

Partitioning

Ensure that there is no swap partition.

Partition Space Allocation Partition Type
NO swap none
/ (root) 20 GB ext4
/home 10 GB ext4
/var Remaining space ext4

Network Requirements

Network Response Time

Spec Web-browser to Datacenter Within Datacenter
Bandwidth 10 Mbps minimum 100 Mbps minimum
Latency 250-300 milliseconds 1 millisecond on LAN

Within the cluster, ideally communication needs to be open - i.e. all cluster nodes should be able to contact all ports of all other cluster nodes.

In case a list of specific ports is needed, refer to this guide.

Internet Connectivity Requirement During updates and initial installation, internet connectivity is needed. For usual operations, internet connectivity isn’t required.

Example Rack Server/Desktop Tower configuration

An example of a single rack server or a desktop tower to support the above deployment would be the following:

Hardware Recommended Spec Example
CPU A CPU with 4 threads Intel i5-7400 or better
RAM 16GB DDR4 or better Corsair LPX 16GB 3200MHz
HDD 256 GB SSD or SAS storage Samsung 860 EVO 250GB SSD

4 or 6 such servers/desktop towers are required to form a cluster as mentioned above.

For any other queries, write to support@gmetri.com


Last update: