Cloud Managed Service | Sisense Community

Community Feedback
Chapters
Events
Forums
Blogs
KB Docs
Support
Learning
Use Case Gallery

Categories

MoreDiscussions

Cloud Managed Service | Sisense Community

Knowledge Base Docs

Cloud Managed Service

Created Apr 15, 2026

2 members

3 discussions

Docs specifically related to Sisense deployments on our Cloud Managed Service.

Cloud Managed Service
Creating and deleting EKS cluster in the existing VPC

Creating and deleting EKS cluster in the existing VPC Introduction: This guide demonstrates how to create an Amazon EKS (Elastic Kubernetes Service) cluster within existing VPCs and subnets, and how to remove it using the same configuration file with a single command. It’s not a recommendation but just an example of the working solution and you have to adjust it according to your needs. Step-by-Step Guide: 1. Prerequisites If you haven’t connected to your AWS account yet, you need to configure it. You can either create a dedicated Linux bastion or use your local laptop. VPC Requirements : Ensure that there is a VPC with both public and private subnets in each of the three availability zones of your chosen region. Each node group must use only one availability zone. AWS CLI Installation : Depending on your operating system (bastion or laptop), install the appropriate version of the AWS CLI (Linux / MacOS / Windows). For installation instructions, visit: AWS CLI Installation . AWS Credentials Configuration : Configure your AWS credentials using one of the available methods. For guidance, refer to: AWS CLI Configuration . Install eksctl : Install the eksctl command-line tool. For installation instructions, visit: eksctl Installation . 2. Setting up cluster.yaml file The configuration below is valid and was tested with eksctl version 0.193.0. Replace the values in metadata.name, region, and the public and private subnet IDs with your own, and save it as cluster.yaml. As for the ‘version’ please refer to the Kubernetes Compatibility Matrix https://docs.sisense.com/main/SisenseLinux/linux-minimum-requirements.htm apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: cluster-test region: us-east-2 version: "1.30" vpc: nat: gateway: Enable subnets: private: us-east-2a: id: subnet-022d3d9104ab651b4 us-east-2b: id: subnet-0b1c2ac0216e101c2 us-east-2c: id: subnet-09c84f9835a0ae13f public: us-east-2a: id: subnet-0fab7bc831ca7a25a us-east-2b: id: subnet-062966c1571fcef50 us-east-2c: id: subnet-08f3dbb5e5fae4b20 managedNodeGroups: - name: query-a labels: node-sisense-Application: "true" node-sisense-Query: "true" iam: withAddonPolicies: autoScaler: true awsLoadBalancerController: true certManager: true ebs: true efs: true fsx: true instanceType: m5a.2xlarge desiredCapacity: 1 minSize: 1 maxSize: 2 volumeSize: 300 availabilityZones: ["us-east-2a"] - name: query-b labels: node-sisense-Application: "true" node-sisense-Query: "true" iam: withAddonPolicies: autoScaler: true awsLoadBalancerController: true certManager: true ebs: true efs: true fsx: true instanceType: m5a.2xlarge desiredCapacity: 1 minSize: 1 maxSize: 2 volumeSize: 300 availabilityZones: ["us-east-2b"] - name: build labels: node-sisense-Build: "true" iam: withAddonPolicies: autoScaler: true awsLoadBalancerController: true certManager: true ebs: true efs: true fsx: true instanceType: m5a.2xlarge desiredCapacity: 1 minSize: 1 maxSize: 2 volumeSize: 300 availabilityZones: ["us-east-2c"] Explanation of YAML Parameters apiVersion : Specifies the version of the eksctl API being used. This is important for compatibility with the features and configurations available in that version. kind : Defines the type of resource being created. In this case, it is a ClusterConfig , which indicates that the configuration is for an EKS cluster. metadata : Contains metadata about the cluster. name : The name of the EKS cluster. This should be unique within the region. region : The AWS region where the cluster will be created (e.g., us-east-2 ). version : The Kubernetes version to be used for the cluster (e.g., "1.30" ). vpc : Configuration related to the Virtual Private Cloud (VPC) where the EKS cluster will be deployed. gateway : Indicates whether to enable a NAT gateway for the cluster. Setting it to Enable allows private subnets to access the internet. private : Lists the private subnets by availability zone, each identified by its subnet ID. public : Lists the public subnets by availability zone, each identified by its subnet ID. nat : Configuration for Network Address Translation (NAT) gateways. subnets : Defines the subnets to be used for the cluster. managedNodeGroups : Configuration for the managed node groups that will run the workloads in the EKS cluster. Each node group can have its own settings. withAddonPolicies : Specifies which AWS services and features the node group should have permissions for, such as: autoScaler : Enables the Kubernetes Cluster Autoscaler. awsLoadBalancerController : Grants permissions for the AWS Load Balancer Controller. certManager : Grants permissions for managing SSL/TLS certificates. ebs : Grants permissions for Amazon Elastic Block Store. efs : Grants permissions for Amazon Elastic File System. fsx : Grants permissions for Amazon FSx. name : The name of the node group. labels : Key-value pairs used to organize and select the nodes in the group. iam : IAM role and policies associated with the node group. instanceType : The EC2 instance type to be used for the nodes (e.g., m5a.2xlarge ). desiredCapacity : The desired number of nodes in the node group. minSize : The minimum number of nodes in the node group. maxSize : The maximum number of nodes in the node group. volumeSize : The size of the EBS volume (in GiB) attached to each node. availabilityZones : Specifies the availability zones where the nodes in the group will be deployed. After setting up file you can create a cluster with the eksctl create cluster -f cluster.yaml command Obtain the kubernetes configuration by running the following command: aws eks update-kubeconfig --region us-east-2 --name cluster-test A shared storage (FSX) must be created manually aws fsx create-file-system --file-system-type LUSTRE --storage-capacity 1200 --tags Key="Name",Value="cluster_test" --subnet-ids "subnet-0b1c2ac0216e101c2" --lustre-configuration "DeploymentType=PERSISTENT_1,PerUnitStorageThroughput=100" --file-system-type LUSTRE - only this type is supported by Sisense --storage-capacity 1200 - the minimal 1200 GB storage for FSX Lustre --tags - update the name and other tags needed --subnet-ids "..." - one of the subnets of your VPC --lustre-configuration - according to the parameters supported https://docs.aws.amazon.com/fsx/latest/LustreGuide/using-fsx-lustre.html Conclusion: A summary of key takeaways or final points. The steps above should help you prepare an EKS cluster for the SIsense installation. The cluster can be deleted with the single command: eksctl delete cluster -f cluster.yaml --disable-nodegroup-eviction References/Related Content: Links and resources for further reading. https://docs.sisense.com/main/SisenseLinux/linux-minimum-requirements.htm https://docs.sisense.com/main/SisenseLinux/autoscaling-and-linux.htm https://docs.sisense.com/main/SisenseLinux/deploying-sisense-on-amazon-eks.htm https://eksctl.io/usage/creating-and-managing-clusters/ https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html https://eksctl.io/installation/ https://docs.aws.amazon.com/fsx/latest/LustreGuide/using-fsx-lustre.html
Oleg ValynkinPosted 1 year ago
0
Cloud Managed Service
High Performance Shared Storage With Trident CSI

When striving to push the boundaries of the Sisense application's performance, it becomes imperative to possess an underlying infrastructure that can seamlessly deliver cutting-edge capabilities. In this regard, the collaborative efforts of Azure and NetApp have yielded the pinnacle of performance solutions – the Astra-Trident Container Storage Interface. Official whitepapers for Azure storage solutions are available here: https://bluexp.netapp.com/blog/astra-blg-comparing-and-contrasting-the-aks-anf-nfs-subdir-external https://learn.microsoft.com/en-us/azure/storage/files/storage-files-netapp-comparison It is important to acknowledge that despite its exceptional attributes, this storage solution may not be ideally suited for every facet of our product due to certain limitations. Consequently, it stands as a fitting choice exclusively for the Shared Storage (RWX) module within our product's architecture. For optimum outcomes, we strongly recommend choosing this solution alongside the managed-csi-premium default AKS storage class for RWO operations during the Sisense deployment process. Deploying the Trident Interface can be summarized in three simple tasks: Deploy the Trident Operator: This is a prerequisite to enable dynamic volume provisioning for Sisense or any other Kubernetes application using Trident. Detailed guidance can be found at: https://docs.netapp.com/us-en/trident/trident-get-started/kubernetes-deploy-operator.html#critical-information-about-astra-trident-23-07 Configure the NetappFiles Backend: This pivotal configuration bestows Trident with the necessary privileges to communicate seamlessly with the underlying storage. The process is outlined comprehensively at: https://docs.netapp.com/us-en/trident/trident-use/anf-prep.html#prerequisites-for-nfs-and-smb-volumes Create a Kubernetes Storage Class: By setting up a dedicated storage class within Kubernetes, applications like Sisense can effortlessly access the underlying storage infrastructure. Detailed steps are provided at: https://docs.netapp.com/us-en/trident/trident-use/create-stor-class.html#configure-a-kubernetes-storageclass-object This configuration harmoniously aligns with the Sisense Helm with Provisioner installation package, facilitating seamless reference to the newly established storage class and default storage class through the persistence.rwxScName and persistence.rwoScName parameters, respectively. When using this configuration, you can leave the persistence.storageType parameter as a set of empty quotes, and ensure sure persistence.enabled is set to true. It is worth noting that this configuration can also be seamlessly extended to cater to customers opting for FSX ONTAP within the AWS ecosystem or Cloud Volume Services within Google Cloud, simply by selecting the appropriate backend configuration under the second step. While deploying Sisense using Helm with Provisioner, under the persistence.rwoScName parameter, you’ll need to use the ebs-csi in modern Kubernetes clusters within AWS environments and in Google Cloud, you can use the standard storage class for the persistence.rwoScName parameter. In summary, NetApp has created a CSI which is highly adaptable and efficient. For Azure customers seeking the best performance possible, review the Trident CSI solution and determine it is best for your environment.
WyattPosted 2 years ago
0
Cloud Managed Service
An universal way on how to collect logs in EKS clusters

Introduction This guide provides step-by-step instructions on how to collect logs in EKS clusters. By following these steps, logs will be copied to a storage location accessible through the Sisense web UI. This approach avoids the need to explain the process to customers, making it more convenient to request logs for troubleshooting and analysis. Prerequisites Access to the control plane to execute kubectl commands. Appropriate permissions to access Sisense web UI. Steps 1. Connect to the Control Plane Before executing any kubectl commands, ensure that you are connected to the Kubernetes control plane. 2. Copy the .log file to a Temporary Location Execute the following command to copy the desired *.log file to a temporary location: kubectl exec -it -n sisense $(kubectl get po -n sisense -l k8s-app=fluentd -o custom-columns=":metadata.name") -- cp /var/log/sisense/sisense/identity.log /tmp/identity.log 3. Copy the .log File from the Temporary Location to the Current Directory. After copying the log file to the temporary location, use the following command to copy it from the temporary location to the current directory: kubectl cp -n sisense $(kubectl get po -n sisense -l k8s-app=fluentd -o custom-columns=":metadata.name"):/tmp/identity.log ./identity.log 4. Copy the .log File to the Storage Folder Now, copy the *.log file from the current directory to the storage folder, which is accessible from the Sisense web UI: kubectl cp -n sisense ./identity.log sisense/$(kubectl get pod -n sisense -l app=management -o jsonpath='{.items[0].metadata.name}'):/opt/sisense/storage/identity0930.log Note: In the above command, replace /var/log/sisense/sisense/identity.log in the first step with the desired log file name, and change identity0930.log in the latest step with the desired log file name. 5. Access Logs from Sisense Web UI The identity0930.log file is now copied to the storage location and can be accessed and downloaded from the Sisense web UI. Follow these steps to access it: Log in to the Sisense web UI. Navigate to the "Admin" tab. Select "System Management" from the options. Click on "File Management." Look for the identity0930.log file and access or download it as needed. Additional Notes In the steps above, we copied the identity.log file and named it identity0930.log in the last step. You can adjust the naming convention as required. Remember to replace the filename in the commands with the desired log file name when working with different logs. Conclusion Following the steps outlined in this article, you can efficiently request logs from customers using Sisense without the need for them to find and access the logs manually. This streamlined process enhances troubleshooting and data analysis capabilities within Sisense for a more effective and seamless experience. Should you require further assistance, kindly reach out to Sisense Support.
Vlad SolodkyiPosted 2 years ago
0