Forum Discussion
What is the best practice to deploy single Tenant in F5 rseries?
Hi, we are going to deploy new rseries 5k with single Tenant. What is the best practice to setup? I plan to setup like below, can someone please advise whether it is correct or not? And I have question on auto disk space and memory allocation. Thanks in advance!
- Allocate all the disk space to this large single tenant
- Allocate all the memory to this single tenant
- within the tenant, set "Large" to "Mgmt" module
- for the rest modules: LTM, GTM , ASM , set "Normal" under Resource Provisioning". Seems the system automatically allocate disk space and memory to each module. Based on the amount of disk space and memory allocated to these modules, seems there are still a lot spare diskspace and memory. Will these modules automatically share the rest spare diskspace and memory when necessary?
Hi Herman2024
Let’s address your setup points one by one and clarify your questions about disk space and memory allocation.
1. Allocate all the disk space to this large single tenant
- This is correct if you are using a single tenant . Allocating the entire disk to the tenant makes sense since you won't be creating multiple tenants and you want to maximize the available resources for this single environment.
- Ensure that you have adequately planned for storage requirements, keeping in mind the modules you are enabling—e.g., ASM (Advanced WAF) tends to require more disk space for logging and rule sets.
2. Allocate all the memory to this single tenant
- Yes, this approach is also correct for a single-tenant setup. Allocating all memory to the tenant ensures that the modules running on that tenant (e.g., LTM, GTM, ASM) have sufficient memory resources.
- Keep in mind that assigning all resources to a single tenant means you're leaving no room for additional tenants in the future. If you anticipate adding tenants down the road, you might want a more reserved strategy.
3. Within the tenant, set "Large" to "Mgmt" module
- This is generally not necessary unless your management module workload (e.g., orchestration, configuration, logging, and device discovery) requires a large amount of resources.
- Typically, the "Mgmt" module can be left as "Normal," unless you anticipate high management traffic (like large-scale logging or API usage). Remember, allocating "Large" consumes more memory and disk space, which might not be needed.
4. For LTM, GTM, ASM, set "Normal" under Resource Provisioning
- Setting "Normal" is appropriate for most use cases. This balances performance and resource allocation for these modules. Keep in mind:
- LTM (Local Traffic Manager) : Used for load balancing and traffic handling, typically runs fine on "Normal."
- GTM (Global Traffic Manager) : Used for DNS and global traffic handling, is usually light on resource usage in most deployments and "Normal" is sufficient.
- ASM (Advanced WAF) : This module can be memory-intensive, depending on the number of policies and request processing load. If you expect heavy ASM usage (e.g., large traffic volumes or complex WAF policies), you may consider setting ASM to "Large." Monitor its memory and disk usage over time to see if adjustments are needed.
Disk Space and Memory Sharing Between Modules
- Does the system automatically allocate disk/memory for each module? Yes! When you provision modules (e.g., LTM, GTM, ASM) as "Normal," "Large," or other resource levels, the system automatically allocates the appropriate amount of memory and disk space for each module based on its provisioning level.
- Do the modules share spare disk and memory when necessary? No, resource provisioning on the platform is static . This means:
- Once a module's disk and memory are assigned, they are reserved for that module and not dynamically adjusted or shared among other modules.
- For example, if ASM is assigned a specific amount of memory and disk space, it will not release or share unused resources with LTM or GTM, even if those modules require more resources.
Recommendations for Optimal Setup:
- Disk and Memory Allocation:
- Allocating everything to a single tenant is fine for a single-tenant environment. Just ensure that you accurately provision each module, keeping future growth in mind.
- Mgmt Module:
- Start with "Normal" for the Mgmt module unless you know for certain your management workloads require "Large." This minimizes over-provisioning.
- Modules (LTM, GTM, ASM):
- Use "Normal" provisioning for most modules.
- If ASM is the most heavily used module (e.g., in security-heavy environments), consider setting it to "Large" for better performance.
- Monitoring and Adjustments:
- After deployment, monitor resource utilization (disk space, memory, and CPU usage) via F5’s management GUI or API.
- If you notice any module is consistently hitting resource limits, you can re-provision or resize the modules as needed.
There are few articles that you can read up.
- Manual : F5 rSeries Systems: Administration and Configuration
- Planning for rSeries Guide
- Manual : F5 rSeries Systems: Getting Started
- MoFaz
Moderator
Hi Herman2024
Let’s address your setup points one by one and clarify your questions about disk space and memory allocation.
1. Allocate all the disk space to this large single tenant
- This is correct if you are using a single tenant . Allocating the entire disk to the tenant makes sense since you won't be creating multiple tenants and you want to maximize the available resources for this single environment.
- Ensure that you have adequately planned for storage requirements, keeping in mind the modules you are enabling—e.g., ASM (Advanced WAF) tends to require more disk space for logging and rule sets.
2. Allocate all the memory to this single tenant
- Yes, this approach is also correct for a single-tenant setup. Allocating all memory to the tenant ensures that the modules running on that tenant (e.g., LTM, GTM, ASM) have sufficient memory resources.
- Keep in mind that assigning all resources to a single tenant means you're leaving no room for additional tenants in the future. If you anticipate adding tenants down the road, you might want a more reserved strategy.
3. Within the tenant, set "Large" to "Mgmt" module
- This is generally not necessary unless your management module workload (e.g., orchestration, configuration, logging, and device discovery) requires a large amount of resources.
- Typically, the "Mgmt" module can be left as "Normal," unless you anticipate high management traffic (like large-scale logging or API usage). Remember, allocating "Large" consumes more memory and disk space, which might not be needed.
4. For LTM, GTM, ASM, set "Normal" under Resource Provisioning
- Setting "Normal" is appropriate for most use cases. This balances performance and resource allocation for these modules. Keep in mind:
- LTM (Local Traffic Manager) : Used for load balancing and traffic handling, typically runs fine on "Normal."
- GTM (Global Traffic Manager) : Used for DNS and global traffic handling, is usually light on resource usage in most deployments and "Normal" is sufficient.
- ASM (Advanced WAF) : This module can be memory-intensive, depending on the number of policies and request processing load. If you expect heavy ASM usage (e.g., large traffic volumes or complex WAF policies), you may consider setting ASM to "Large." Monitor its memory and disk usage over time to see if adjustments are needed.
Disk Space and Memory Sharing Between Modules
- Does the system automatically allocate disk/memory for each module? Yes! When you provision modules (e.g., LTM, GTM, ASM) as "Normal," "Large," or other resource levels, the system automatically allocates the appropriate amount of memory and disk space for each module based on its provisioning level.
- Do the modules share spare disk and memory when necessary? No, resource provisioning on the platform is static . This means:
- Once a module's disk and memory are assigned, they are reserved for that module and not dynamically adjusted or shared among other modules.
- For example, if ASM is assigned a specific amount of memory and disk space, it will not release or share unused resources with LTM or GTM, even if those modules require more resources.
Recommendations for Optimal Setup:
- Disk and Memory Allocation:
- Allocating everything to a single tenant is fine for a single-tenant environment. Just ensure that you accurately provision each module, keeping future growth in mind.
- Mgmt Module:
- Start with "Normal" for the Mgmt module unless you know for certain your management workloads require "Large." This minimizes over-provisioning.
- Modules (LTM, GTM, ASM):
- Use "Normal" provisioning for most modules.
- If ASM is the most heavily used module (e.g., in security-heavy environments), consider setting it to "Large" for better performance.
- Monitoring and Adjustments:
- After deployment, monitor resource utilization (disk space, memory, and CPU usage) via F5’s management GUI or API.
- If you notice any module is consistently hitting resource limits, you can re-provision or resize the modules as needed.
There are few articles that you can read up.
- Manual : F5 rSeries Systems: Administration and Configuration
- Planning for rSeries Guide
- Manual : F5 rSeries Systems: Getting Started
- Herman2024
Cirrostratus
Hi MoFaz , thanks a lot for your advice. Just one more question:
After Resource provisioning for a particular module ( for example LTM), the system automatically assigned disk space and memory to this module. As F5 rseries has a large disk space and memory, is it possible to manually assign more disk space and memory to this particular module LTM using any command? please advise,thanks.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com