#
2008.09.30 凌晨1:30，可愛的女兒出生。
給她起名叫歆懌，即開開心心，高高興興的意思。
希望她一定過得比她爸爸好，活得比她爸爸精彩。
轉：
http://news.csdn.net/n/20060801/93169.html
這篇文章中，我們選用MySQL 4.0.2-alpha與PostgreSQL 7.2進行比較，因為MySQL 4.0.2-alpha開始支持事務的概念，因此這樣的比較對于MySQL應該較為有利。
我們這樣的比較不想僅僅成為一份性能測試報告，因為至少從我個人來看，對于一個數據庫，穩定性和速度并不能代表一切。對于一個成熟的數據庫，穩定性肯定會日益提供。而隨著硬件性能的飛速提高，速度也不再是什么太大的問題。
一、兩者的共同優勢
這兩個產品都屬于開放源碼的一員，性能和功能都在高速地提高和增強。MySQL AB的人們和PostgreSQL的開發者們都在盡可能地把各自的數據庫改得越來越好，所以對于任何商業數據庫使用其中的任何一個都不能算是錯誤的選擇。
二、兩者不同的背景
MySQL的背后是一個成熟的商業公司，而PostgreSQL的背后是一個龐大的志愿開發組。這使得MySQL的開發過程更為慎重，而PostgreSQL的反應更為迅速。
這樣的兩種背景直接導致了各自固有的優點和缺點。
三、MySQL的主要優點
1、首先是速度，MySQL通常要比PostgreSQL快得多。MySQL自已也宣稱速度是他們追求的主要目標之一，基于這個原因，MySQL在以前的文檔中也曾經說過并不準備支持事務和觸發器。但是在最新的文檔中，我們看到MySQL 4.0.2-alpha已經開始支持事務，而且在MySQL的TODO中，對觸發器、約束這樣的注定會降低速度的功能也列入了日程。但是，我們仍然有理由相信，MySQL將有可能一直保持速度的優勢。
2、MySQL比PostgreSQL更流行，流行對于一個商業軟件來說，也是一個很重要的指標，流行意味著更多的用戶，意味著經受了更多的考驗，意味著更好的商業支持、意味著更多、更完善的文檔資料。
3、與PostgreSQL相比，MySQL更適宜在Windows環境下運行。MySQL作為一個本地的Windows應用程序運行(在NT/Win2000/WinXP下，是一個服務)，而PostgreSQL是運行在Cygwin模擬環境下。PostgreSQL在Windows下運行沒有MySQL穩定，應該是可以想象的。
4、MySQL使用了線程，而PostgreSQL使用的是進程。在不同線程之間的環境轉換和訪問公用的存儲區域顯然要比在不同的進程之間要快得多。
5、MySQL可以適應24/7運行。在絕大多數情況下，你不需要為MySQL運行任何清除程序。PostgreSQL目前仍不完全適應24/7運行，這是因為你必須每隔一段時間運行一次VACUUM。
6、MySQL在權限系統上比PostgreSQL某些方面更為完善。PostgreSQL只支持對于每一個用戶在一個數據庫上或一個數據表上的INSERT、SELECT和UPDATE/DELETE的授權，而MySQL允許你定義一整套的不同的數據級、表級和列級的權限。對于列級的權限，PostgreSQL可以通過建立視圖，并確定視圖的權限來彌補。MySQL還允許你指定基于主機的權限，這對于目前的PostgreSQL是無法實現的，但是在很多時候，這是有用的。
7、由于MySQL 4.0.2-alpha開始支持事務的概念，因此事務對于MySQL不再僅僅成為劣勢。相反，因為MySQL保留無事務的表類型。這就為用戶提供了更多的選擇。
8、MySQL的MERGE表提供了一個獨特管理多個表的方法。
9、MySQL的myisampack可以對只讀表進行壓縮，此后仍然可以直接訪問該表中的行。
四、PostgreSQL的主要優點：
1、對事務的支持與MySQL相比，經歷了更為徹底的測試。對于一個嚴肅的商業應用來說，事務的支持是不可或缺的。
2、MySQL對于無事務的MyISAM表。采用表鎖定，一個長時間運行的查詢很可能會長時間地阻礙對表的更新。而PostgreSQL不存在這樣的問題。
3、PostgreSQL支持存儲過程，而目前MySQL不支持，對于一個嚴肅的商業應用來說，作為數據庫本身，有眾多的商業邏輯的存在，此時使用存儲過程可以在較少地增加數據庫服務器的負擔的前提下，對這樣的商業邏輯進行封裝，并可以利用數據庫服務器本身的內在機制對存儲過程的執行進行優化。此外存儲過程的存在也避免了在網絡上大量的原始的SQL語句的傳輸，這樣的優勢是顯而易見的。
4、對視圖的支持，視圖的存在同樣可以最大限度地利用數據庫服務器內在的優化機制。而且對于視圖權限的合理使用，事實上可以提供行級別的權限，這是MySQL的權限系統所無法實現的。
5、對觸發器的支持，觸發器的存在不可避免的會影響數據庫運行的效率，但是與此同時，觸發器的存在也有利于對商業邏輯的封裝，可以減少應用程序中對同一商業邏輯的重復控制。合理地使用觸發器也有利于保證數據的完整性。
6、對約束的支持。約束的作用更多地表現在對數據完整性的保證上，合理地使用約束，也可以減少編程的工作量。
7、對子查詢的支持。雖然在很多情況下在SQL語句中使用子查詢效率低下，而且絕大多數情況下可以使用帶條件的多表連接來替代子查詢，但是子查詢的存在在很多時候仍然不可避免。而且使用子查詢的SQL語句與使用帶條件的多表連接相比具有更高的程序可讀性。
8、支持R-trees這樣可擴展的索引類型，可以更方便地處理一些特殊數據。
9、PostgreSQL可以更方便地使用UDF(用戶定義函數)進行擴展。
五、那么我究竟應該使用MySQL還是PostgreSQL
這個問題很難說得清，而且事實上除了MySQL和PostgreSQL外，使用Oracle、Sybase、Informix等也是明智的選擇。如何你確定只在MySQL和PostgreSQL中進行選擇，以下規則總是有效的。
1、如果你的操作系統是Windows，你應該使用MySQL。
2、如果你對數據庫并不了十分了解，甚至不知道事務、存儲過程等究竟是什么，你應該使用MySQL。
3、如果你的應用對數據的完整性和嚴肅性要求不高，但是追求處理的高速度。例如是一個論壇和社區，你應該使用MySQL。
4、你的應用是一個嚴肅的商業應用，對數據完整性要求很高。而且你希望對一些商業數據邏輯進行很好的封裝，例如是一個網上銀行，你應該使用PostgreSQL。
5、你的應用處理的是地理數據，由于R-TREES的存在，你應該使用PostgreSQL。
6、你是一個數據庫內核的狂熱愛好者，你甚至希望擁有你自己版本的數據庫，毫無疑問，你必須使用PostgreSQL，沒準下一個PostgreSQL版本中某一個模塊的作者就是你。
六、后記
以上只是作者從自己的理解盡量客觀公正地評價MySQL和PostgreSQL的優劣。其中的帶有傾向性的意見只代表作者個人觀點，有關這兩個數據庫，歡迎廣大朋友提出自己的看法。
http://en.wikipedia.org/wiki/VTP
VLAN Trunking Protocol (VTP) is a Cisco proprietary Layer 2 messaging protocol that manages the addition, deletion, and renaming of VLANs on a network-wide basis. Virtual Local Area Network (VLAN) Trunk Protocol (VTP) reduces administration in a switched network. When you configure a new VLAN on one VTP server, the VLAN is distributed through all switches in the domain. This reduces the need to configure the same VLAN everywhere. To do this VTP carries VLAN information to all the switches in a VTP domain. VTP advertisements can be sent over ISL, 802.1q, IEEE 802.10 and LANE trunks. VTP traffic is sent over the management VLAN (VLAN1), so all VLAN trunks must be configured to pass VLAN1. VTP is available on most of the Cisco Catalyst Family products.
You can configure a switch to operate in any one of these VTP modes:
-
Server—In VTP server mode, you can create, modify, and delete VLANs and specify other configuration parameters, such as VTP version and VTP pruning, for the entire VTP domain. VTP servers advertise their VLAN configuration to other switches in the same VTP domain and synchronize their VLAN configuration with other switches based on advertisements received over trunk links. VTP server is the default mode.
-
Client—VTP clients behave the same way as VTP servers, but you cannot create, change, or delete VLANs on a VTP client.
-
Transparent—VTP transparent switches do not participate in VTP. A VTP transparent switch does not advertise its VLAN configuration and does not synchronize its VLAN configuration based on received advertisements, but transparent switches do forward VTP advertisements that they receive out their trunk ports in VTP Version 2.
-
Off (configurable only in CatOS switches)—In the three described modes, VTP advertisements are received and transmitted as soon as the switch enters the management domain state. In the VTP off mode, switches behave the same as in VTP transparent mode with the exception that VTP advertisements are not forwarded.
http://en.wikipedia.org/wiki/Spanning_tree_protocol
The Spanning Tree Protocol is an OSI layer-2 protocol that ensures a loop-free topology for any bridged LAN. It is based on an algorithm invented by Radia Perlman while working for Digital Equipment Corporation. Spanning tree allows a network design to include spare (redundant) links to provide automatic backup paths if an active link fails, without the danger of bridge loops, or the need for manual enabling/disabling of these backup links. Bridge loops must be avoided because they result in flooding the network.
The Spanning Tree Protocol (STP), is defined in the IEEE Standard 802.1D. As the name suggests, it creates a spanning tree within a mesh network of connected layer-2 bridges (typically Ethernet switches), and disables those links that are not part of the tree, leaving a single active path between any two network nodes.
http://en.wikipedia.org/wiki/VLAN
A virtual LAN, commonly known as a VLAN, is a group of hosts with a common set of requirements that communicate as if they were attached to the Broadcast domain, regardless of their physical location. A VLAN has the same attributes as a physical LAN, but it allows for end stations to be grouped together even if they are not located on the same network switch. Network reconfiguration can be done through software instead of physically relocating devices.
Uses
VLANs are created to provide the segmentation services traditionally provided by routers in LAN configurations. VLANs address issues such as scalability, security, and network management. Routers in VLAN topologies provide broadcast filtering, security, address summarization, and traffic flow management. By definition, switches may not bridge IP traffic between VLANs as it would violate the integrity of the VLAN broadcast domain.
This is also useful if one wants to create multiple Layer 3 networks on the same Layer 2 switch. For example if a DHCP server (which will broadcast its presence) were plugged into a switch it would serve anyone on that switch that was configured to do so. By using VLANs you easily split the network up so some hosts won't use that server and default to Link-local addresses.
Virtual LANs are essentially Layer 2 constructs, compared with IP subnets which are Layer 3 constructs. In a LAN employing VLANs, a one-to-one relationship often exists between VLANs and IP subnets, although it is possible to have multiple subnets on one VLAN or have one subnet spread across multiple VLANs. Virtual LANs and IP subnets provide independent Layer 2 and Layer 3 constructs that map to one another and this correspondence is useful during the network design process.
By using VLAN, one can control traffic patterns and react quickly to relocations. VLANs provide the flexibility to adapt to changes in network requirements and allow for simplified administration.
Motivation
In a legacy network, users were assigned to networks based on geography and were limited by physical topologies and distances. VLANs can logically group networks so that the network location of users is no longer so tightly coupled to their physical location. Technologies able to implement VLANs are:
Asynchronous Transfer Mode (ATM)
Fiber Distributed Data Interface (FDDI)
Fast Ethernet
Gigabit Ethernet
10 Gigabit Ethernet
HiperSockets
Protocols and design
The protocol most commonly used today in configuring virtual LANs is IEEE 802.1Q. The IEEE committee defined this method of multiplexing VLANs in an effort to provide multivendor VLAN support. Prior to the introduction of the 802.1Q standard, several proprietary protocols existed, such as Cisco's ISL (Inter-Switch Link, a variant of IEEE 802.10) and 3Com's VLT (Virtual LAN Trunk). ISL is no longer supported by Cisco.
Both ISL and IEEE 802.1Q tagging perform explicit tagging as the frame is tagged with VLAN information explicitly. ISL uses an external tagging process that does not modify the existing Ethernet frame whereas 802.1Q uses an internal tagging process that does modify the Ethernet frame. This internal tagging process is what allows IEEE 802.1Q tagging to work on both access and trunk links, because the frame appears to be a standard Ethernet frame.
The IEEE 802.1Q header contains a 4-byte tag header containing a 2-byte tag protocol identifier (TPID) and a 2-byte tag control information (TCI). The TPID has a fixed value of 0x8100 that indicates that the frame carries the 802.1Q/802.1p tag information. The TCI contains the following elements:
Three-bit user priority
One-bit canonical format indicator (CFI)
Twelve-bit VLAN identifier (VID)-Uniquely identifies the VLAN to which the frame belongs
The 802.1Q standard can create an interesting scenario on the network. Recalling that the maximum size for an Ethernet frame as specified by IEEE 802.3 is 1518 bytes, this means that if a maximum-sized Ethernet frame gets tagged, the frame size will be 1522 bytes, a number that violates the IEEE 802.3 standard. To resolve this issue, the 802.3 committee created a subgroup called 802.3ac to extend the maximum Ethernet size to 1522 bytes. Network devices that do not support a larger frame size will process the frame successfully but may report these anomalies as a "baby giant."
Inter-Switch Link (ISL) is a Cisco proprietary protocol used to interconnect multiple switches and maintain VLAN information as traffic travels between switches on trunk links. This technology provides one method for multiplexing bridge groups (VLANs) over a high-speed backbone. It is defined for Fast Ethernet and Gigabit Ethernet, as is IEEE 802.1Q. ISL has been available on Cisco routers since Cisco IOS Software Release 11.1.
With ISL, an Ethernet frame is encapsulated with a header that transports VLAN IDs between switches and routers. ISL does add overhead to the packet as a 26-byte header containing a 10-bit VLAN ID. In addition, a 4-byte CRC is appended to the end of each frame. This CRC is in addition to any frame checking that the Ethernet frame requires. The fields in an ISL header identify the frame as belonging to a particular VLAN.
A VLAN ID is added only if the frame is forwarded out a port configured as a trunk link. If the frame is to be forwarded out a port configured as an access link, the ISL encapsulation is removed.
Early network designers often configured VLANs with the aim of reducing the size of the collision domain in a large single Ethernet segment and thus improving performance. When Ethernet switches made this a non-issue (because each switch port is a collision domain), attention turned to reducing the size of the broadcast domain at the MAC layer. Virtual networks can also serve to restrict access to network resources without regard to physical topology of the network, although the strength of this method remains debatable as VLAN Hopping [1] is a common means of bypassing such security measures.
Virtual LANs operate at Layer 2 (the data link layer) of the OSI model. Administrators often configure a VLAN to map directly to an IP network, or subnet, which gives the appearance of involving Layer 3 (the network layer). In the context of VLANs, the term "trunk" denotes a network link carrying multiple VLANs, which are identified by labels (or "tags") inserted into their packets. Such trunks must run between "tagged ports" of VLAN-aware devices, so they are often switch-to-switch or switch-to-router links rather than links to hosts. (Note that the term 'trunk' is also used for what Cisco calls "channels" : Link Aggregation or Port Trunking). A router (Layer 3 device) serves as the backbone for network traffic going across different VLANs.
On Cisco devices, VTP (VLAN Trunking Protocol) maintains VLAN configuration consistency across the entire network. VTP uses Layer 2 trunk frames to manage the addition, deletion, and renaming of VLANs on a network-wide basis from a centralized switch in the VTP server mode. VTP is responsible for synchronizing VLAN information within a VTP domain and reduces the need to configure the same VLAN information on each switch.
VTP minimizes the possible configuration inconsistencies that arise when changes are made. These inconsistencies can result in security violations, because VLANs can crossconnect when duplicate names are used. They also could become internally disconnected when they are mapped from one LAN type to another, for example, Ethernet to ATM LANE ELANs or FDDI 802.10 VLANs. VTP provides a mapping scheme that enables seamless trunking within a network employing mixed-media technologies.
VTP provides the following benefits:
VLAN configuration consistency across the network
Mapping scheme that allows a VLAN to be trunked over mixed media
Accurate tracking and monitoring of VLANs
Dynamic reporting of added VLANs across the network
Plug-and-play configuration when adding new VLANs
As beneficial as VTP can be, it does have disadvantages that are normally related to the Spanning Tree Protocol (STP) as a bridging loop propagating throughout the network can occur. Cisco switches run an instance of STP for each VLAN, and since VTP propagates VLANs across the campus LAN, VTP effectively creates more opportunities for a bridging loop to occur.
Before creating VLANs on the switch that will be propagated via VTP, a VTP domain must first be set up. A VTP domain for a network is a set of all contiguously trunked switches with the same VTP domain name. All switches in the same management domain share their VLAN information with each other, and a switch can participate in only one VTP management domain. Switches in different domains do not share VTP information.
Using VTP, each Catalyst Family Switch advertises the following on its trunk ports:
Management domain
Configuration revision number
Known VLANs and their specific parameters
Establishing VLAN memberships
The two common approaches to assigning VLAN membership are as follows:
Static VLANs
Dynamic VLANs
Static VLANs are also referred to as port-based VLANs. Static VLAN assignments are created by assigning ports to a VLAN. As a device enters the network, the device automatically assumes the VLAN of the port. If the user changes ports and needs access to the same VLAN, the network administrator must manually make a port-to-VLAN assignment for the new connection.
Dynamic VLANs are created through the use of software packages such as CiscoWorks 2000. With a VLAN Management Policy Server VMPS, an administrator can assign switch ports to VLANs dynamically based on information such as the source MAC address of the device connected to the port or the username used to log onto that device. As a device enters the network, the device queries a database for VLAN membership. See also FreeNAC which implements a VMPS server.
Port-based VLANs
With port-based VLAN membership, the port is assigned to a specific VLAN independent of the user or system attached to the port. This means all users attached to the port should be members in the same VLAN. The network administrator typically performs the VLAN assignment. The port configuration is static and cannot be automatically changed to another VLAN without manual reconfiguration.
As with other VLAN approaches, the packets forwarded using this method do not leak into other VLAN domains on the network. After a port has been assigned to a VLAN, the port cannot send to or receive from devices in another VLAN without the intervention of a Layer 3 device.
The device that is attached to the port likely has no understanding that a VLAN exists. The device simply knows that it is a member of a subnet and that the device should be able to talk to all other members of the subnet by simply sending information to the cable segment. The switch is responsible for identifying that the information came from a specific VLAN and for ensuring that the information gets to all other members of the VLAN. The switch is further responsible for ensuring that ports in a different VLAN do not receive the information.
This approach is quite simple, fast, and easy to manage in that there are no complex lookup tables required for VLAN segmentation. If port-to-VLAN association is done with an application-specific integrated circuit (ASIC), the performance is very good. An ASIC allows the port-to-VLAN mapping to be done at the hardware level.
Protocol Based VLANs
This section needs additional citations for verification.
Please help improve this article by adding reliable references. Unsourced material may be challenged and removed. (February 2008)
In a protocol based VLAN enabled switch, traffic is forwarded through ports based on protocol. Essentially user tries to segregate or forward a particular protocol traffic from a port using the protocol based VLANs, traffic from any other protocol is not forwarded on the port. For example, if you have connected a host, pumping ARP traffic on the switch at port 10, connected a Lan pumping IPX traffic to the port 20 of the switch and connected a router pumping IP traffic on port 30. then if you define a protocol based VLAN supporting IP and including all the three ports 10, 20 and 30 then IP packets can be forwarded to the ports 10 and 20 also , but ARP traffic will not get forwarded to the ports 20 and 30, similarly IPX traffic will not get forwarded to ports 10 and 30.
http://en.wikipedia.org/wiki/Link_Layer_Discovery_Protocol
The Link Layer Discovery Protocol or LLDP is a vendor-neutral Layer 2 protocol that allows a network device to advertise its identity and capabilities on the local network. The protocol was formally ratified as IEEE standard 802.1AB-2005 in May 2005. It supersedes proprietary protocols like Cisco Discovery Protocol, Extreme Discovery Protocol and Nortel Discovery Protocol (also known as SONMP).
Information gathered with LLDP are stored in the device and can be queried using Simple Network Management Protocol. The topology of a LLDP-enabled network can be discovered by crawling the hosts and querying this database. Information that can be retrieved include:
system name and description
port name and description
VLAN name
IP management address
system capabilities (switching, routing, etc.)
MAC/PHY information
MDI power
link aggregation
Support
LLDP is still young but is supported on various types of equipment:
HP ProCurve switches and routers
Extreme switches and routers
Nortel 55x0 and 425 series
Allied Telesis switches and routers
Cisco switchs and routers with recent IOS
Alcatel-Lucent switches with AOS > 6.3.1
Juniper EX series switches
AASTRA 9480i (35i) and 675i series VoIP phones
Enterasys Secure Networks
如果所有設備都支持LLDP，那拓撲發現程序就很容易寫了。
http://en.wikipedia.org/wiki/Cisco_Discovery_Protocol
The Cisco Discovery Protocol (CDP) is a proprietary layer 2 network protocol developed by Cisco Systems that runs on most Cisco equipment and is used to share information about other directly connected Cisco equipment such as the operating system version and IP address. CDP can also be used for On-Demand Routing (ODR), which is a method of including routing information in CDP announcements so that dynamic routing protocols do not need to be used in simple networks.
Cisco devices send CDP announcements to the multicast destination address 01-00-0c-cc-cc-cc (also used for other Cisco proprietary protocols such as VTP). CDP announcements (if supported and configured in IOS) are sent by default every 60 seconds on interfaces that support Subnetwork Access Protocol (SNAP) headers, including Ethernet, Frame Relay and ATM. Each Cisco device that supports CDP stores the information received from other devices in a table that can be viewed using the show cdp neighbors command. The CDP table's information is refreshed each time an announcement is received, and the holdtime for that entry is reset. The holdtime specifies how long an entry in the table will be kept - if no announcements are received from a device and the holdtime timer expires for that entry, the device's information is discarded (default 180 seconds).
The information contained in CDP announcements varies by the type of device and the version of the operating system running on it. Information contained includes the operating system version, hostname, every address for every protocol configured on the port where CDP frame is sent eg. IP address, the port identifier from which the announcement was sent, device type and model, duplex setting, VTP domain, native VLAN, power draw (for Power over Ethernet devices), and other device specific information. The details contained in these announcements is easily extended due to the use of the type-length-value (TLV) frame format. See external links for a technical definition.
HP removed support for sending CDP from HP Procurve products shipping after February 2006 and all future software upgrades. Receiving CDP and showing neighbor information is still supported. CDP support was replaced with LLDP.
Conclusions and Lessons Learned
What are the key lessons we have learned? In no particular order:
Address the provision of systems management in prioritized, manageable units of work. Don't try to do everything at once.
Manage the rollout of your systems management application just like any other implementation. After all, availability and integrity of your management application should ideally exceed that of the most critical component that it manages.
Get buy in from all the stakeholders in the process, from Management to Shift Operators.
Think about who will use the tool. You probably don't want to send alerts regarding printer failures to your DBA team. Similarly it's probably not a good idea to send arcane messages about network topology changes to application support teams. Prioritize system alerts and trim out noise.
Don't use it a stick to beat developers, network admin or systems admin staff. If your network management tool highlights a problem, use that information as a justification to provide the resources to fix it.
Do your research. Adopting an Open Source solution requires just as much rigor in the selection and evaluation process as a proprietary solution. By all means download your candidate solution and try it out, but don't allow a machine under a Systems Administrator's desk to become a mission critical component.
It's not been a totally smooth ride. We had repeated problems with memory leaks within the Java virtual machine (admittedly, not OpenNMS's fault). We also had a few nasty problems with corruption of OpenNMS's back-end database, which are now fixed. There were also a lot of "d'oh!" moments along the way, as we got up to speed with what is a pretty complex application. None of these problems ever seemed like show stoppers at the time. This had much to do with help extended by the development team and user community, to whom we extend our thanks.
Why OpenNMS?
OpenNMS checked a lot of these boxes. It was (mostly) java, so we could run it on our Sun hardware. OpenNMS was already running in environments an order of magnitude larger than ours. It had a lot of the enterprise level features absent from other Open Source products. There were documents available on the Internet [1],[2] that pointed to its extensibility. It was based on a lot of familiar components (tomcat, postgres, rrdtool). Finally, in Open Source terms, it was a relatively mature product.
We took a cautious approach deploying OpenNMS.
Simplest to replace, and therefore first to go were the existing network monitoring products. Only after a month of parallel running with OpenNMS did we decommission our existing solutions.
Second to go were the diverse collection of emails that were sent by applications or batch jobs. We replaced the destination email addresses with some mailboxes that delivered the notifications directly into OpenNMS. This turned out to be a bigger win than we'd expected. By having a central point where application alerts could be received and processed, we revealed hidden issues with applications that had existed for weeks or months.
This was painful at first. The respective teams were often uncomfortable in having their problems aired to the world. Once we started to address these problems, however, and the frequency of the alerts started to reduce, we started to see real benefits. The operations team had a single console to monitor applications, and we could reduce the number of application support staff on call.
The next target was system performance data collected by our existing tools. That which could be readily moved into OpenNMS went quickly. Platform specific data collectors (such as those which collected from Microsoft hosts using WMI) had any important alerts channeled in to OpenNMS.
Our current focus, now that we believe our OpenNMS installation is mature, is back in application space. We are extending the end-to-end monitoring capabilities of OpenNMS to our web services providers. We are also starting to use it to retrieve instrumentation data directly from applications themselves, as well as their hosts.
Did We Meet Our Requirements?
Here's how things shook out:
Platform independence: Yes. OpenNMS can run on spare hardware. But it's not a good idea. A year after our first rollout of OpenNMS, we moved from a shared SUN Ultrasparc 2 machine to a dedicated dual Xeon machine running RedHat Advanced Server.
Performance: Yes. We are comfortable in that there will always be users pushing the scalability of OpenNMS much harder than we are.
Enterprise Level Features: A cautious yes. OpenNMS met our initial requirements, but also quickly highlighted new ones. Some customers are never satisfied.
Rationalize Support Roles: Yes. OpenNMS is now the single point for the distribution of all actionable network, server and application events. This does need to be constantly policed, to ensure that non-standard notification paths do not creep in again.
Reduce Tasks: A cautious yes. In general, the operator's load has lessened, if only because it has reduced the numbers of open windows on their desktops.
Extensibility: Yes. OpenNMS has proved to be highly extensible.
Low cost of entry: We deployed OpenNMS with minimal capital outlay. We believe that the subsequent people based operational costs have been roughly equivalent to those of a commercial solution.
Longevity: We seem to have backed a product with "legs." The mailing lists [3] are as busy as ever and new features are being added to OpenNMS faster than we can make use of them.
The "sweet spot" for OpenNMS seems to be about as wide as any Open Source solution and getting bigger by the month. We look forward to enhancements in the web user interface, a new JMX based data collector and support for event correlation in the near future.
Why Do We Need a Systems Management Tool?
Current trends in the IT world continue to accelerate the rate of change in every area. Applications, server platforms and networks are no longer the slow moving entities they once were. They are subject to change on an almost daily basis. In this environment, it becomes more and more important for the IT Operations team to quickly detect, and respond to changes, or anomalous events.
My employer is a relatively new business. Applications would be customized packages, and a large section of its core IT systems would be outsourced. Slowly, those package based solutions morphed into custom applications and, for a variety of reasons, these outsourced systems were brought back in-house a couple of years ago. This presented those of us in the IT department with some interesting challenges. One of those challenges was how to go about managing our newly re-acquired IT infrastructure and applications.
When we first decided to move our core systems from an outsourced to an in-house IT Operations Department, our requirements were limited. Checking the availability of some services and the load on the network and key servers was about as much as we thought we needed.
It became obvious over time that this was rather optimistic. Each new service added seemed to result in a new management tool being installed on a System Administrator's workstation. At one point we had three separate network monitoring systems, three separate performance management tools and a plethora different scripts, web pages and command line tools. The DBA team had one tool, the Network Admins another, the Unix and Windows teams yet another. We sent out critical alerts by email, pager, and SMS, often to completely inappropriate people.
The company was growing, and it looked like it was beginning to need a grown-up systems management tool, but which one?
What Do We Expect from a Systems Management Application?
There is definitely a "sweet spot" for systems management applications. Some are suited to smaller environments, others are most definitely suited to enterprise scale environments with more demanding requirements. Unsurprisingly the enterprise scale products often come with enterprise scale price tags and learning curves.
We had a few key requirements:
Platform independence: Our network management system would have to run on available hardware (at the time, SPARC/Solaris).
Performance: Any solution would need to scale from a few hundred nodes to a few thousand nodes.
Enterprise level features: We required at least SNMP trap management, configurable alert escalation and availability and performance reports for the management team.
Rationalize support roles: We needed to be able to take individuals out of the process. That meant an end to emails sent by systems to developers in the middle of the night. Our operations team needed to be the first contact for every event.
Reduce tasks: It would need to lighten the burden on the Operations Team, not increase it.
Extensibility: Previous experience indicated that there was no such thing as a complete solution.
Low cost of entry: It needed to replace a portfolio of Open Source products.
Longevity: Some Open Source products seem to wither on the vine with no apparent cause, or fragment through disagreements between developers. Commercial products too are subject to the vagaries of the market.
摘要: package afu.mymail;
import java.io.*;
import javax.mail.internet.*;
import javax.mail.*;
import java.util.*;
public class RecieveMail
{
...
閱讀全文
摘要: package afu.proxy;
import java.net.*;
import java.io.*;
import org.apache.commons.httpclient.*;
import org.apache.commons.httpclient.methods.*;
public class&nb...
閱讀全文
N/A是指：Not Applicable。不是Not Available 的縮寫。
是指表格中空出的地方要填的一欄，與你的情況不合。N/A是你填進去的字，不是原有印在上面的。比如表格要你填state或prorinve，但你的國家或你住的地方，沒有“省”這個概念，如有的國家，國家下面就是“區”了。還有，有的表格問你有幾個孩子，你連結婚都沒有結，自然填N/A。
見下面N/A即Not Applicable的釋意：
A commonly used abbreviation in the English language for the lack of data in a form or table field, because it does not apply to the situation.
Ethernet Frame Formats:
Ethernet (a.k.a. Ethernet II)
+---------+---------+---------+----------
| Dst | Src | Type | Data...
+---------+---------+---------+----------
<-- 6 --> <-- 6 --> <-- 2 --> <-46-1500->
Type 0x80 0x00 = TCP/IP
Type 0x06 0x00 = XNS
Type 0x81 0x37 = Novell NetWare
802.3
+---------+---------+---------+----------
| Dst | Src | Length | Data...
+---------+---------+---------+----------
<-- 6 --> <-- 6 --> <-- 2 --> <-46-1500->
802.2 (802.3 with 802.2 header)
+---------+---------+---------+-------+-------+-------+----------
| Dst | Src | Length | DSAP | SSAP |Control| Data...
+---------+---------+---------+-------+-------+-------+----------
<- 1 -> <- 1 -> <- 1 -> <-43-1497->
SNAP (802.3 with 802.2 and SNAP headers)
+---------+---------+---------+-------+-------+-------+-----------+---------+-----------
| Dst | Src | Length | 0xAA | 0xAA | 0x03 | Org Code | Type | Data...
+---------+---------+---------+-------+-------+-------+-----------+---------+-----------
<-- 3 --> <-- 2 --> <-38-1492->
Ethernet中存在這四種Frame的格式，如果不能很好的區分他們，那么肯定會造成網絡的混亂，
現實中網絡設備可以很好的識別它們，那么網絡設備又是如何識別的呢?
(1) 如何區分EthernetII與其他格式的幀
如果幀頭跟隨source mac地址的2 bytes的值大于1500則此Frame為EthernetII格式的。否則就是其他格式的幀。
(2)其他幀格式的區別
接著比較緊接著的兩bytes如果為0xFFFF則為Novell Ethernet 類型的Frame
如果為0xAAAA則為Ethernet SNAP格式的Frame ，如果都不是則為Ethernet
802.3/802.2格式的幀
在/etc/profile加入
export JAVA_HOME=/usr/java/jdk1.6.0_06
export PATH=$JAVA_HOME/bin:$CATALINA_HOME/bin:$PATH
export TOMCAT_HOME=/software/apache-tomcat-6.0.16
export BASEDIR=/software/apache-tomcat-6.0.16
export CATALINA_BASE=/software/apache-tomcat-6.0.16
export CATALINA_HOME=/software/apache-tomcat-6.0.16
export CATALINA_TMPDIR=/software/apache-tomcat-6.0.16/temp
重啟后，用java -version查看
[root@afunms bin]# java -version
java version "1.6.0_06"
Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing)