Oracle Solaris 11.2：IP服务质量管理指南

需积分: 0 111 浏览量更新于2024-06-25 收藏 1MB PDF 举报

"Oracle Solaris 11.2 管理IP服务质量在Oracle Solaris 11.2-104中的应用" Oracle Solaris 11.2 提供了强大的网络服务质量（QoS，Quality of Service）管理功能，允许系统管理员对网络流量进行精细控制，确保关键业务的数据传输得到优先处理，同时优化整体网络性能。本资源可能是一份详细的指南，旨在帮助IT专业人员理解和实施Oracle Solaris 11.2环境中的IP QoS策略。在Oracle Solaris 11.2中，IP QoS是通过集成在网络堆栈中的多个组件实现的，这些组件包括流量控制、调度算法、带宽管理以及优先级服务。以下是一些关键知识点： 1. **流量控制**：流量控制机制用于限制发送到网络的流量速率，防止拥塞。在Oracle Solaris中，可以使用如TCP pacing这样的技术来平滑发送速率，减少拥塞并改善网络效率。 2. **调度算法**：不同的调度算法（如WFQ，Weighted Fair Queuing或PIFS，Priority-based Flow Scheduling）被用于决定数据包的发送顺序。这些算法可以确保高优先级的流量得到及时处理，同时保持低优先级流量的公平性。 3. **带宽管理**：Oracle Solaris提供了带宽管理工具，如bwlimit，允许设定特定接口或会话的最大带宽，防止某些应用占用过多资源，从而影响其他应用的性能。 4. **优先级服务**：通过设置DSCP（Differentiated Services Code Point）字段，可以标记数据包的优先级，使得网络设备可以根据这些标记对数据包进行优先处理。 5. **策略管理**：策略管理工具如ipfsmgr和dtrace，提供了一种方式来创建、应用和监视QoS策略。这些工具可以帮助管理员根据需要调整网络行为。 6. **网络监控与分析**：Oracle Solaris 11.2可能包含强大的诊断和监控工具，如ipcs，ipcrm，和netstat，它们有助于识别网络瓶颈，优化QoS策略。 7. **兼容性和互操作性**：对于美国政府或其他需要符合特定安全标准的组织，Oracle Solaris的QoS功能应满足相关的合规性要求，如文档中提及的“U.S. GOVERNMENT END USERS”条款。了解和掌握这些知识点，IT专业人员能够更有效地配置和维护Oracle Solaris 11.2网络环境，确保关键服务的可靠性，并在需要时进行故障排查和性能优化。这份文档可能是这些技术的详细指南，提供了实践指导和案例研究，以帮助读者深入理解并实际操作IP QoS管理。

Differentiated Services Model

16 Managing IP Quality of Service in Oracle Solaris 11.2 • July 2014

IPQoS Filters

Filters are sets of rules that contain parameters called selectors. Each filter must point to a

class. IPQoS matches packets against the selectors of each filter to determine whether the

packet belongs to the filter's class. You can filter on a packet by using a variety of selectors, for

example, the IPQoS 5-tuple and other common parameters:

■

Source address and destination addresses

■

Source port and destination port

■

Protocol numbers

■

User IDs

■

Project IDs

■

Differentiated Services Codepoint (DSCP)

■

Interface index

For example, a simple filter might include the destination port with the value of 80. The ipgpc

classifier then selects all packets that are bound for destination port 80 (HTTP) and handles the

packets as directed in the QoS policy.

For information about creating filters, see “How to Define Filters in the QoS

Policy” on page 31.

Meter (tokenmt and tswtclmt) Overview

In the Diffserv model, the meter tracks the transmission rate of traffic flows on a per-class basis.

The meter evaluates how much the actual rate of the flow conforms to the configured rates to

determine the appropriate outcome. Based on the traffic flow's outcome, the meter selects a

subsequent action, such as sending the packet to another action or returning the packet to the

network without further processing.

The IPQoS meters determine whether a network flow conforms to the transmission rate that is

defined for its class in the QoS policy. IPQoS includes two metering modules:

■

tokenmt – Uses a two-token bucket metering scheme

■

tswtclmt – Uses a time-sliding window metering scheme

Both metering modules recognize three outcomes: red, yellow, and green. You

define the actions to be taken for each outcome in the parameters red_action_name,

yellow_action_name, and green_action_name.

In addition, you can configure tokenmt to be color aware. A color-aware metering instance uses

the packet's size, DSCP, traffic rate, and configured parameters to determine the outcome. The

meter uses the DSCP to map the packet's outcome to green, yellow, or red.

Traffic Forwarding on an IPQoS-Enabled Network

Chapter1 • Introducing IPQoS 19

3. The classifier sends to the marker any traffic that does not require flow control.

4. Traffic to be flow-controlled is sent to the meter.

5. The meter enforces the configured rate. Then, the meter assigns a traffic conformance value

to the flow-controlled packets.

6. The flow-controlled packets are then evaluated to determine if any packets require

accounting.

7. The meter sends to the marker any traffic that does not require flow accounting.

8. The flow-accounting module gathers statistics on received packets. The module then sends

the packets to the marker.

9. The marker assigns a DS codepoint to the packet header. This DSCP indicates the per-hop

behavior that a Diffserv-aware system must apply to the packet.

Traffic Forwarding on an IPQoS-Enabled Network

This section introduces the elements that are involved in forwarding packets on an IPQoS-

enabled network. An IPQoS-enabled system handles any packets on the network stream with

the system's IP address as the destination. The IPQoS system then applies its QoS policy to the

packet to establish differentiated services.

DS Codepoint

The DS codepoint (DSCP) defines in the packet header the action that any Diffserv-aware

system should take on a marked packet. The Diffserv architecture defines a set of DS

codepoints for the IPQoS-enabled system and Diffserv router to use. The Diffserv architecture

also defines forwarding behaviors, which correspond to the DSCPs. The IPQoS-enabled

system marks the precedence bits of the DS field in the packet header with the DSCP. When a

router receives a packet with a DSCP value, the router applies the forwarding behavior that is

associated with that DSCP. The packet is then released onto the network.

Note - The dlcosmk marker does not use the DSCP. Instead, dlcosmk marks Ethernet frame

headers with a CoS value. If you plan to configure IPQoS on a network that uses VLAN

devices, refer to “Marker Module” on page 88.

Per-Hop Behaviors

In Diffserv terminology, the forwarding behavior that is assigned to a DSCP is called the

per-hop behavior (PHB). The PHB defines the forwarding precedence that a marked packet

Traffic Forwarding on an IPQoS-Enabled Network

20 Managing IP Quality of Service in Oracle Solaris 11.2 • July 2014

receives in relation to other traffic on the Diffserv-aware system. This precedence ultimately

determines whether the IPQoS-enabled system or Diffserv router forwards or drops the

marked packet. For a forwarded packet, each Diffserv router that the packet encounters en

route to its destination applies the same PHB unless another Diffserv system has changed the

DSCP. For more information about PHBs, refer to “Using the dscpmk Marker for Forwarding

Packets” on page 89.

The goal of a PHB is to provide a specified amount of network resources to a class of traffic

on the contiguous network. In the QoS policy, you define DSCPs that indicate the precedence

levels for traffic classes when the traffic flows leave the IPQoS-enabled system. Precedences

can range from high-precedence/low-drop probability to low-precedence/high-drop probability.

For example, your QoS policy can assign to one class of traffic a DSCP that guarantees a

low-drop precedence PHB from any Diffserv-aware router, which guarantees bandwidth to

packets of this class. You can add to the QoS policy other DSCPs that assign varying levels

of precedence to other traffic classes. The lower-precedence packets are given bandwidth by

Diffserv systems in agreement with the priorities that are indicated in the packets' DSCPs.

IPQoS supports two types of forwarding behaviors, which are defined in the Diffserv

architecture: expedited forwarding (EF) and assured forwarding (AF).

■

Expedited forwarding

This per-hop behavior assures that any traffic class with EFs related DSCP is given highest

priority. Traffic with an EF DSCP is not queued. EF provides low loss, latency, and jitter.

The recommended DSCP for EF is 101110. A packet that is marked with 101110 receives

guaranteed low-drop precedence as the packet traverses Diffserv-aware networks en route

to its destination. Use the EF DSCP when assigning priority to customers or applications

with a premium SLA.

■

Assured forwarding

This per-hop behavior provides four different forwarding classes that you can assign to a

packet. Every forwarding class provides three drop precedences: low-drop, medium-drop,

and high-drop. For more detailed information, see Table 6-2. The various AF codepoints

provide the ability to assign different levels of service to customers and applications.

Packet Forwarding in a Diffserv Environment

The following figure shows part of an intranet at a company with a partially Diffserv-enabled

environment. In this scenario, all hosts on networks 10.10.0.0 and 10.14.0.0 are IPQoS

enabled, and the local routers on both networks are Diffserv aware. However, the interim

networks are not configured for Diffserv.

剩余103页未读，继续阅读

weixin_40191861_zj

粉丝: 83
资源: 1万+

Oracle Solaris 11.2：IP服务质量管理指南

Oracle Solaris 11.2 Administering TCP/IP Networks, IPMP, and IP

Oracle Solaris 11.1 Managing IP Quality of Service in Oracle Sol

Oracle Solaris 11.2 Managing Devices in Oracle Solaris 11.2-256

Oracle Solaris 11.2 Managing Auditing in Oracle Solaris 11.2-15

Oracle Solaris 11.2 Managing Faults in Oracle Solaris 11.2-24

Oracle Solaris 11.3 Managing IP Quality of Service-110

Oracle Solaris 11.2 Managing Network File Systems in Oracle Sol

Oracle Solaris 11.2 Managing ZFS File Systems in Oracle Solaris

Oracle Solaris 11.2 Managing sendmail Services in Oracle Solaris

Oracle Solaris 11.2 Managing Network Datalinks in Oracle Solaris

最新资源