Can physical server Intranets under different accounts communicate with each other?
No, generated arrears cannot be offset by resource packages.
The Intranet communication between physical servers is limited to resources under the same account or tenant. By default, physical servers under different accounts cannot directly communicate with each other over Intranet. To make physical servers under different accounts communicate with each other over Intranet, take into account the use of security groups, VPC peering, or other network connection methods to implement Intranet communication across accounts. These methods provide a secure and controllable Intranet communication solution.
How can two physical servers in the same region but different availability zones communicate with each other?
Two physical servers in the same region but different availability zones can communicate with each other in the following ways:
1. Ensure that two physical servers reside in the same virtual private cloud (VPC).
2. Create subnets in the same VPC and assign the two physical servers to different subnets.
3. Assign an elastic IP to each physical server. Bind the elastic IP to the active NIC of the physical server to enable access to the Internet.
4. Configure appropriate network access rules in the security group to allow communication between two physical servers.
5. If the two physical servers are on the same subnet, tier 2 communication can be implemented. If two physical servers are in different subnets, tier 3 communication is required, that is, forwarding packets through a router.
Are the physical servers I created on the same subnet?
You can customize the network and determine whether to deploy the physical servers on the same subnet.
If you select the same subnet when you create physical servers, the physical servers will be on the same subnet.
If you select different subnets when you create physical servers, the physical servers will be on different subnets.
Can a physical server be associated with multiple security groups?
Elastic bare metal can be associated with multiple security groups.
By adding elastic bare metal to different security groups, you can apply multiple security rules to the elastic bare metal to provide more flexible and fine-grained network access control. In this way, security isolation and protection can be implemented at different levels to meet different requirements. By properly configuring security group rules, you can restrict inbound and outbound traffic, control source and destination IP addresses, ports, and protocol types, and thus strengthen the network security protection of elastic bare metal.
Note: If the elastic bare metal belongs to multiple security groups, all security group rules will apply. Therefore, when you manage and configure security group rules, ensure that the rules are consistent and coordinated to avoid possible network communication failures.
Can a physical server communicate with an elastic cloud server in the same VPC?
Yes.
When the physical server resides in the same subnet as the elastic cloud server, they can directly communicate with each other without going through a router. You can configure security group rules to allow traffic transmission between physical servers and elastic cloud servers.
Can a physical server be bound to multiple EIPs?
Yes.
For elastic bare metal of multi-AZ resource pools, multiple NICs can be bound to an EIP. Each elastic NIC can be bound to an independent elastic IP. Perform the following operations:
1. Go to the details page for the physical server instance for which you want to bind an elastic IP.
2. Go to EIP > Bind EIP, select the EIP to bind on the screen, and click OK.
Can I manually set an elastic IP address?
No, generated arrears cannot be offset by resource packages.
Elastic IP addresses are automatically assigned from the DHCP address pool and cannot be manually set.
Will the released elastic IP addresses be repeatedly assigned when I apply for it again?
This cannot be guaranteed.
After an EIP is released, the EIP is returned to the address pool and will be randomly assigned again. If the EIP is only temporarily disabled and you want to continue using it, we recommend that you do not release it, and instead, keep the EIP and disable it so that it can be bound to another instance if necessary. This ensures that you can continue to use the specific EIP.
What are the differences between elastic IP addresses, private IP addresses, and virtual IP addresses?
Elastic IP addresses are used for access to the Internet, private IP addresses are used for internal communication, and virtual IP addresses are used for high availability active/standby switchover. Each IP address plays a different role in different scenarios and needs:
· An elastic IP address (EIP) is a public IP address that can directly access the Internet. It is used to provide services to the outside world and access the Internet. Each EIP can be bound to only one instance or load balancer.
· A private IP address is an IP address used on the public cloud Intranet for internal communication and exchange between cloud resources. A private IP cannot directly access the Internet and is only valid within internal networks.
· A virtual IP (VIP) address, also known as, floating IP address, is used to achieve high availability. It is usually used in active/standby server switchover scenarios. When the active server fails, the virtual IP address can be quickly switched to the standby server to ensure continuous service availability. A virtual IP address is a logical IP address that is used to direct requests to an active server.
How can I modify the network configuration of the physical server or restart the network when I can only log in to the physical server using SSH?
The network automatically allocated by the physical server cannot be modified. If the network is modified when only SSH login is available, the physical server may not be connected. If a physical server uses a custom VLAN NIC, you can configure or modify the network of the NIC in the following steps:
1. Log in to the operating system on which the physical server is running using SSH.
2. Run the following command to get the current network configuration:
ifconfig
or
ip addr show
3. Edit the network configuration file as needed. The file path and editing method may vary depending on the operating system. For example, in CentOS/RHEL, the network configuration file is located in the /etc/sysconfig/network-scripts/ directory. The file name is usually ifcfg-<NIC name> (for example, ifcfg-eth0). You can use a text editor (such as vi, nano) to open the file and edit it.
4. Edit the network configuration as needed, such as IP address, subnet mask, gateway, and DNS.
5. Save your settings and exit the editor.
6. Run the following command to take network configuration into effect:
systemctl restart network
7. Check whether the network configuration takes effect. You can run the ifconfig or ip addr show command again to view the new network configuration.
What should I do if I cannot ping the extended NIC in the CentOS 7 series?
You can try the following solutions if you cannot ping the extended NIC in the CentOS 7 series:
1. First, check whether your CentOS 7 version is 7.4 or later. If so, it may be affected by a known kernel issue.
2. We recommend that you upgrade the operating system kernel to CentOS 7.5 or later. You can download the CentOS 7.5 kernel file from the operating system official website and upload it to the physical server.
3. Run the following command to install the updated kernel:
yum install kernel-3.10.0-862.el7.x86_64.rpm
Description
If "Automatically mount EVS" is configured in /etc/fstab, comment out the automatic mounting items in /etc/fstab before updating the kernel. Otherwise, you cannot access the operating system normally upon restart.
4. Restart the physical server for the new kernel to take effect.
5. After logging in to the operating system, reinstall the CentOS 7.5 driver to ensure normal communication with the extended NIC.
What should I do with the co-plane communication error between the active and extended NICs of a physical server?
The following procedure shows how to shoot the trouble with the co-plane communication error between the active and extended NICs of a physical server:
1. Check whether the active and extended NICs are correctly configured. Check that the IP address, subnet mask, and gateway are correctly set in the network configuration file (for example, the /etc/sysconfig/network-scripts/ifcfg-ethX file in CentOS).
2. Check the configuration of network devices, such as switches. Ensure that the network devices connected to the active and extended NICs work properly, are configured correctly, and have no faults or limitations.
3. Ensure that the routes between the subnets (VPC, network, etc.) where the active and extended NICs reside are correctly configured. Check the routing table and routing configuration of network devices to ensure that packets are correctly forwarded to the destination subnet.
4. Check the firewall settings. Firewall rules may restrict communication between the active and extended NICs. Ensure that firewall rules allow the required communication traffic.
5. Check whether the network configuration of the server is in conflict. For example, ensure that the IP addresses and subnet masks of the active and extended NICs do not conflict with each other.
6. Test the network connectivity. Use a tool, for example, the ping command, or another network connectivity test tool to test the connectivity between the active NIC and the extended NIC. If the connectivity is abnormal, conduct further investigation according to the test result.