How many server IP addresses does an enterprise need when deploying an internal web system? This question primarily depends on the system's architectural complexity, high availability requirements, security policies, and future expansion plans. Proper IP planning is the cornerstone of a stable internal network infrastructure; haphazard allocation can lead to chaotic network management, difficulties in expansion, and even security vulnerabilities later on. Understanding the underlying logic and considerations is far more important than memorizing a specific number.

To improve availability, the most common practice is to deploy components with different functionalities on separate servers, which typically requires at least two IP addresses. A classic "front-end/back-end separation" architecture deploys the web server (such as Nginx or Apache) and the back-end application server (such as Tomcat or Node.js) separately. The web server needs one IP address to handle HTTP requests, serve static files, and forward dynamic requests to the back-end. The application server needs another IP address to run the core business logic. If a separate database (such as MySQL or PostgreSQL) is also used, a third IP address is needed. Thus, a basic but complete three-tier architecture (web layer, application layer, data layer) requires at least three independent IP addresses. This separation brings many benefits: each layer can be independently expanded, upgraded, and maintained; security policies can be more granular, such as allowing only the web server to access specific ports of the application server; and the system's fault tolerance is also improved.

When the system needs to ensure high availability, i.e., eliminate single points of failure, the number of IP addresses required increases significantly. This involves clustering and load balancing technologies. Taking the web layer as an example, if two Nginx servers are deployed for load balancing and failover, each server needs its own IP address. In addition, a "virtual IP address" is usually introduced. This VIP is not bound to a specific physical server, but is jointly maintained by the two servers through software like Keepalived. Users and upstream systems always access this VIP, and when the primary server fails, the backup server automatically takes over the VIP, achieving seamless failover. Therefore, a high-availability web layer alone may require three IP addresses: two real IPs for the two physical machines, and one virtual IP for external service.

Extending this model to the entire system makes the requirements clearer. A three-tier architecture with high availability requires IP addresses as follows: the load balancer layer (two machines plus one VIP) needs 3 IPs; the application server cluster (assuming two instances) needs 2 IPs; and the database layer using master-slave replication (one master and one slave) needs 2 IPs. Therefore, a minimum-scale high-availability intranet system requires at least 7 IP addresses. This does not include the IPs needed for supporting facilities such as monitoring servers, log collection servers, backup servers, or jump servers.

Besides core business servers, the enterprise intranet environment must also consider security partitioning. Following the principles of "least privilege" and "layered defense," production, testing, and development environments typically need to be deployed in logically or physically isolated network segments. This means that the set of IP addresses planned for the production environment (e.g., the 7 calculated above) also needs to be prepared for one set for the testing environment and another set for the development environment. If the three networks are completely isolated, IP addresses can be reused (e.g., 10.0.1.0/24 for the production network and 10.0.2.0/24 for the test network, both starting from 1). However, in terms of total planned capacity, the required address space increases exponentially.

Future scalability is a margin that must be included in the planning. When allocating IPs to each server role, the allocation should not be based solely on the current number. For example, if the application server currently has only 2 instances deployed, the planning should reserve IP addresses for a potential expansion to 6 instances within a year. A good practice is to use "subnetting" and "IP range reservation." A large internal network address range (e.g., 10.0.0.0/16) can be divided into multiple subnets, reserving contiguous address blocks for different purposes.

Below is an example of an address range planned for a medium-sized enterprise's intranet applications, assuming the use of the Class B private address range 10.1.0.0/16:

# Core Production Environment Subnet: 10.1.1.0/24

10.1.1.1-10 Reserved (network devices, gateways, etc.)

10.1.1.11-20 Load Balancer and VIP

10.1.1.21-40 Web/Proxy Server

10.1.1.41-80 Application Server Cluster

10.1.1.81-100 Database Server

10.1.1.101-120 Caching Server (Redis/Memcached)

10.1.1.121-140 Monitoring, Log, and Backup Server

10.1.1.141-254 Reserved for the Future

# Test environment subnet: 10.1.2.0/24

# Similar structure to the production environment, address range: 10.1.2.1 - 10.1.2.254

# Development environment subnet: 10.1.3.0/24

# Similar structure to the production environment, address range: 10.1.3.1 - 10.1.3.254

This planning method is clear and easy to manage. When a new application server needs to be added, the administrator can sequentially select an unused IP from the address pool of 10.1.1.41-80 for allocation, without having to search for one temporarily.

Besides business systems, there are some special IP requirements that need to be considered. For example, servers may need out-of-band management ports (such as iDRAC, iLO). These management network cards usually need to be configured in a separate management network segment, consuming additional IP addresses. In a virtualization environment, the host machine itself needs an IP address, and each virtual machine on it also needs an IP address. Containerized deployments (such as Kubernetes) introduce the concepts of Pod networks and Service networks. These require entire segments of IP addresses to be allocated to Pods and Services, typically necessitating the pre-planning of a large subnet.

In summary, for a formally used enterprise intranet web system, planning from a dozen to several dozen IP addresses is common and reasonable. The key is not pursuing the minimum number, but rather building a clear, stable, and easily scalable network foundation through rigorous planning. This is the truly essential core consideration for enterprise deployments.