Ошибка сетевого интерфейса ucs

R_KING

Еще вопрос — firmware и BIOS обновлять последовательно с повышением версии или можно на initial сразу накатить последнее обновление?

R_KING

R_KING

Неужели никто с таким модулем не сталкивался?

real1st

R_KING

real1st

R_KING

General Troubleshooting Solutions

Faults

In Cisco UCS, a fault is a mutable object that is managed by Cisco UCS Manager. Each fault represents a failure in the Cisco UCS domain or an alarm threshold that has been raised. During the lifecycle of a fault, it can change from one state or severity to
another.

Each fault includes information about the operational state of the affected object at the time the fault was raised. If the
fault is transitional and the failure is resolved, the object transitions to a functional state.

A fault remains in Cisco UCS Manager until the fault is cleared and deleted according to the settings in the fault collection policy.

You can view all faults in a Cisco UCS domain from either the Cisco UCS Manager CLI or the Cisco UCS Manager GUI. You can also configure the fault collection policy to determine how a Cisco UCS domain collects and retains faults.

Note	All Cisco UCS faults are included in MIBs and can be trapped by SNMP.

Fault Severities

A fault raised in a Cisco UCS domain can transition
through more than one severity during its lifecycle. The following table describes the fault
severities that you may encounter.

Severity	Description
Critical	Service-affecting condition that requires immediate corrective action. For example, this severity could indicate that the managed object is out of service and its capability must be restored.
Major	Service-affecting condition that requires urgent corrective action. For example, this severity could indicate a severe degradation in the capability of the managed object and that its full capability must be restored.
Minor	Nonservice-affecting fault condition that requires corrective action to prevent a more serious fault from occurring. For example, this severity could indicate that the detected alarm condition is not degrading the capacity of the managed object.
Warning	Potential or impending service-affecting fault that has no significant effects in the system. You should take action to further diagnose, if necessary, and correct the problem to prevent it from becoming a more serious service-affecting fault.
Condition	Informational message about a condition, possibly independently insignificant.
Info	Basic notification or informational message, possibly independently insignificant.

Fault States

A fault raised in a Cisco UCS domain transitions
through more than one state during its lifecycle. The following table describes the possible
fault states in alphabetical order.

State	Description
Cleared	Condition that has been resolved and cleared.
Flapping	Fault that was raised, cleared, and raised again within a short time interval, known as the flap interval.
Soaking	Fault that was raised and cleared within a short time interval, known as the flap interval. Because this state may be a flapping condition, the fault severity remains at its original active value, but this state indicates the condition that raised the fault has cleared.

Fault Types

A fault raised in a Cisco UCS domain can be
one of the types described in the following table.

Type	Description
fsm	FSM task has failed to complete successfully, or Cisco UCS Manager is retrying one of the stages of the FSM.
equipment	Cisco UCS Manager has detected that a physical component is inoperable or has another functional issue.
server	Cisco UCS Manager cannot complete a server task, such as associating a service profile with a server.
configuration	Cisco UCS Manager cannot successfully configure a component.
environment	Cisco UCS Manager has detected a power problem, thermal problem, voltage problem, or loss of CMOS settings.
management	Cisco UCS Manager has detected a serious management issue, such as one of the following: Critical services could not be started The primary fabric interconnect could not be identified Components in the Cisco UCS domain include incompatible firmware versions
connectivity	Cisco UCS Manager has detected a connectivity problem, such as an unreachable adapter.
network	Cisco UCS Manager has detected a network issue, such as a link down.
operational	Cisco UCS Manager has detected an operational problem, such as a log capacity issue or a failed server discovery.
generic	Cisco UCS Manager has detected a generic issue, such as Board Controller upgrade requires a manual power cycle of the server.
sysdebug	Cisco UCS Manager has detected a system debug issue, such as auto core transfer failure at remote server since the remote server is not accessible or because the remote server details for transfer are incorrect.
security	Cisco UCS Manager has detected a security issue, such as invalid certificate.
chassis profile	This fault is raised when Cisco UCS Manager cannot complete a chassis task, such as associating a chassis profile with a chassis.

Fault
Properties

Cisco UCS Manager provides detailed information about each fault raised in a
Cisco UCS domain. The following table describes the fault properties that you can
view in
Cisco UCS Manager CLI or
Cisco UCS Manager GUI.

Property Name	Description
Severity	Current severity level of the fault, which can be any of the severities described in Fault Severities .
Last Transition	Day and time on which the severity for the fault last changed. If the severity has not changed since the fault was raised, this property displays the original creation date.
Affected Object	Component that is affected by the condition that raised the fault.
Description	Description of the fault.
ID	The unique identifier associated with the message.
Type	Type of fault that has been raised, which can be any of the types described in Fault Types .
Cause	Unique identifier associated with the condition that caused the fault.
Created at	Day and time when the fault occurred.
Code	The unique identifier assigned to the fault.
Number of Occurrences	Number of times the event that raised the fault occurred.
Original Severity	Severity assigned to the fault the first time it occurred.
Previous Severity	Previous severity level. This property is only used if the severity of a fault changes during its lifecycle.
Highest Severity	Highest severity encountered for this issue.

Lifecycle of Faults

Faults in Cisco UCS are stateful. Only one instance of a given fault can exist on each object. If the same fault occurs a second time, Cisco UCS increases the number of occurrences by one.

A fault has the following lifecycle:

1. A condition occurs in the system and
   Cisco UCS Manager
   raises a fault. This is the active state.

2. When the fault is alleviated, it enters a flapping or soaking interval that is designed to prevent flapping. Flapping occurs
   when a fault is raised and cleared several times in rapid succession. During the flapping interval, the fault retains its
   severity for the length of time specified in the fault collection policy.

3. If the condition reoccurs during the flapping interval, the fault returns to the active state. If the condition does not reoccur
   during the flapping interval, the fault is cleared.

4. The cleared fault enters the retention interval. This interval ensures that the fault reaches the attention of an administrator
   even if the condition that caused the fault has been alleviated and the fault has not been deleted prematurely. The retention
   interval retains the cleared fault for the length of time specified in the fault collection policy.

5. If the condition reoccurs during the retention interval, the fault returns to the active state. If the condition does not
   reoccur, the fault is deleted.

Faults in Cisco UCS Manager GUI

If you want to view faults for a single object in the system, navigate to that object in the Cisco UCS Manager GUI and click the Faults tab in the Work pane. If you want to view faults for all objects in the system, navigate to the Faults node on the Admin tab under Faults, Events and Audit Log.

In addition, you can also view a summary of all faults in a Cisco UCS domain in the Fault Summary area in the upper left of the Cisco UCS Manager GUI. This area provides a summary of all faults that have occurred in the Cisco UCS domain.

Each fault severity is represented by a different icon. The number below each icon indicates how many faults of that severity
have occurred in the system. If you click an icon, the Cisco UCS Manager GUI opens the Faults tab in the Work pane and displays the details of all faults with that severity.

Faults in Cisco UCS
Manager CLI

If you want to view
the faults for all objects in the system, enter the
show fault
command from the top-level scope. If you want to view the faults for a specific
object, scope to that object and then execute the
show fault
command.

If you want to view
all available details about a fault, enter the
show fault
detail command.

Fault Collection Policy

The fault collection policy controls the lifecycle of a fault in the Cisco UCS domain, including the length of time that each fault remains in the flapping and retention intervals.

Syslog

The syslog provides a central point for collecting and processing system logs that you can use to troubleshoot and audit a
Cisco UCS domain. Cisco UCS Manager relies on the Cisco NX-OS syslog mechanism and API, and on the syslog feature of the primary fabric interconnect to collect
and process the syslog entries.

Cisco UCS Manager collects and logs syslog messages internally. You can send them to external syslog servers running a syslog
daemon. Logging to a central syslog server helps in aggregation of logs and alerts. Some syslog messages to monitor include,
DIMM problems, equipment failures, thermal problems, voltage problems, power problems, high availability (HA) cluster problems,
and link failures.

Note	The FSM faults, threshold faults, and unresolved policy events are not sent to syslog server. However, SNMP traps are generated for the threshold fault events.

Cisco UCS Manager manages and configures the syslog collectors for a Cisco UCS domain and deploys the configuration to the fabric interconnect or fabric interconnects. This configuration affects all syslog entries
generated in a Cisco UCS domain by Cisco NX-OS or by Cisco UCS Manager.

You can configure Cisco UCS Manager to do one or more of the following with the syslog and syslog entries:

• Display the syslog entries in the console or on the monitor

• Store the syslog entries in a file

• Forward the syslog entries to up to three external log collectors where the syslog for the Cisco UCS domain is stored

Syslog messages contain an event code and fault code. To monitor syslog messages, you can define syslog message filters. These
filters can parse the syslog messages based on the criteria you choose. You can use the following criteria to define a filter:

• By event or fault codes: Define a filter with a parsing rule to include only the specific codes that you intend to monitor.
  Messages that do not match these criteria are discarded.

• By severity level: Define a filter with a parsing rule to monitor syslog messages with specific severity levels. You can set
  syslog severity levels individually for OS functions, to facilitate logging and display of messages ranging from brief summaries
  to detailed information for debugging.

Syslog Entry Format

Each syslog entry generated by a Cisco UCS component is formatted
as follows:

Year month date hh:mm:ss hostname %facility-severity-MNEMONIC description

For example: 2007 Nov 1 14:07:58 excal-113 %MODULE-5-MOD_OK: Module
1 is online

Syslog Entry Severities

A syslog entry is assigned a Cisco UCS severity by Cisco UCS Manager. The following table shows how the Cisco UCS severities
map to the syslog severities.

Table 4. Syslog Entry Severities in Cisco UCS

Cisco UCS Severity	Syslog Severity
CRIT	CRIT
MAJOR	ERR
MINOR	WARNING
WARNING	NOTICE
INFO	INFO

Syslog Entry Parameters

The following table describes the information
contained in each syslog entry.

Table 5. Syslog Message Content

Name	Description
Facility	Logging facility that generated and sent the syslog entry. The facilities are broad categories that are represented by integers. These sources can be one of the following standard Linux facilities: local0 local1 local2 local3 local4 local5 local6 local7
Severity	Severity of the event, alert, or issue that caused the syslog entry to be generated. The severity can be one of the following: emergencies critical alerts errors warnings information notifications debugging
Hostname	Hostname included in the syslog entry that depends upon the component where the entry originated, as follows: The fabric interconnect, Cisco UCS Manager, or the hostname of the Cisco UCS domain For all other components, the hostname associated with the virtual interface (VIF)
Timestamp	Date and time when the syslog entry was generated.
Message	Description of the event, alert, or issue that caused the syslog entry to be generated.

Syslog Services

The following Cisco UCS components use the Cisco NX-OS syslog services to generate syslog entries for system information and
alerts:

• I/O module—All syslog entries are sent by syslogd to the fabric interconnect to which it is connected.

• CIMC—All syslog entries are sent to the primary fabric interconnect in a cluster configuration.

• Adapter—All syslog entries are sent by NIC-Tools/Syslog to both fabric interconnects.

• Cisco UCS Manager—Self-generated syslog entries are logged according to the syslog configuration.

Technical Support
Files

When you encounter an
issue that requires troubleshooting or a request for assistance to the Cisco
Technical Assistance Center (Cisco Technical Assistance Center), collect as much information as possible about the affected
Cisco UCS domain.
Cisco UCS Manager outputs this information into a tech support file that you can
send to Cisco.

You can create a tech
support file for the following components of a
Cisco UCS domain:

• UCSM—Contains
  technical support data for the entire
  Cisco UCS domain.

• UCSM management services—Contains technical support data for the
  Cisco UCS Manager
  management services, excluding Fabric Interconnects.

• Chassis—Contains
  technical support data for the I/O module or the CIMCs on the blade servers in
  a given chassis only.

• Fabric
  extender—Contains technical support data for the given FEX.

• Rack
  server—Contains technical support data for the given rack-mount server and
  adapter.

• Server memory—Contains server memory technical support data for the
  given rack-mount servers and blade servers.

Creating a Tech
Support File in the Cisco UCS Manager GUI

Note	In releases earlier than Cisco UCS Manager Release 1.4(1), you can create a technical support file only in the Cisco UCS Manager CLI.

Procedure

---

Step 1	In the Navigation pane, click Admin.
Step 2	Expand .
Step 3	In the Work pane, click Create and Download Tech Support.
Step 4	In the Path field in the Create and Download a Tech Support File dialog box, enter the full path where the technical support file should be saved. This path must be locally accessible. If you do not know the path, click the Browse button to navigate to it. Name Description Path field The full path where the technical support file should be saved. This path must be locally accessible.
Step 5	In the Options area, click one of the following radio buttons: Option Description ucsm Creates a file containing technical support data for the entire Cisco UCS domain. If you select ucsm, Cisco UCS Manager GUI displays the following options: Exclude Commands—Reduces the size of the tech support file by excluding all CLI commands. Include Fabric Interconnect Trace Logs—Includes any trace logs generated by the fabric interconnects. You should only check these options if directed to do so by Cisco Technical Assistance Center. ucsm-mgmt Creates a file containing technical support data for the Cisco UCS management services, excluding the fabric interconnects. If you select ucsm-mgmt, Cisco UCS Manager GUI displays the following options: Exclude Commands—Reduces the size of the tech support file by excluding all CLI commands. Include Fabric Interconnect Trace Logs—Includes any trace logs generated by the fabric interconnects. You should only check these options if directed to do so by Cisco Technical Assistance Center. chassis Creates a file containing technical support data for either the CIMCs or I/O modules in a given chassis. When you select this option, Cisco UCS Manager GUI displays the following fields: Chassis ID field—The chassis for which you want technical support data. CIMC radio button—Select this option to get CIMC technical support data. To get the data for a single server within the chassis, enter that server’s ID in the CIMC ID field. To get the CIMC data for all servers in the chassis, enter all in this field. IOM radio button—Select this option to get I/O module technical support data. To get the data for a single server within the chassis, enter that server’s ID in the IOM ID field. To get the I/O module data for all servers in the chassis, enter all in this field. fabric-extender Creates a file containing technical support data for a fabric extender. When you select this option,Cisco UCS Manager GUI displays the FEX ID field that lets you enter the unique identifier of the FEX for which you want technical support data. rack-server Creates a file containing technical support data for a C-Series server. When you select this option, Cisco UCS Manager GUI displays the following fields: Rack Server ID field—The unique identifier of the rack server, or the rack server number for which you want technical support data. For example, 4 or 7. Rack Server Adapter ID field—The unique identifier of the adapter for which you want technical support data. To get the data for all adapters in the server, enter all in this field. server-memory Saves a file containing server memory technical support data for B-Series and C-Series servers to the specified directory. When you select this option, Cisco UCS Manager GUI displays the following field: Server IDs field—The comma-separated list of unique identifiers of the blade servers and rack servers for which you want detailed server memory technical support data. For blade servers, each server ID is in the following form—chassis-num/blade-server-num. For example, 1/3 or 4/5. For rack servers, each server ID is the following form—rackserver-num. For example, 4 or 7.
Step 6	Click OK.

---

Creating a Technical
Support File in the Cisco UCS Manager CLI

Use the
show
tech-support command to output information about a
Cisco UCS domain that you can send to
Cisco Technical Assistance Center.

Procedure

	Command or Action	Purpose
Step 1	UCS-A# connect local-mgmt {a | b}	Enters local management mode.
Step 2	UCS-A(local-mgmt) # show tech-support {chassis chassis-id {all | cimc slot [adapter adapter-id] | iom iom-id} | fex fex-id | server server-id [adapter adapter-id] | server-memory {server-list | all } | ucsm | ucsm-mgmt } [brief | detail ]	Outputs information about the selected objects in a file that you can send to Cisco Technical Assistance Center. The following options are available: chassis—Creates file containing technical support data for either the CIMCs or I/O modules in a given chassis. fex—Creates a file containing technical support data for a fabric extender. server—Creates a file containing technical support data for a C-Series server. server-memory—Creates a technical support file with all server memory related information. You can run the server-memory command for the following: One blade server or rack-mount server Multiple blade servers Multiple rack-mount servers A mix of blade and rack-mount servers All servers Important  Multiple servers specified in the server-list must be separated by commas. You cannot run this command for a range of servers. If you use the server-memory option with the detail option, detailed information about the memory is saved into a file and the file name and path are displayed. ucsm—Creates a file containing technical support data for the entire Cisco UCS domain. ucsm-mgmt—Creates a file containing technical support data for the Cisco UCS management services, excluding the fabric interconnects.
Step 3	UCS-A (local-mgmt) # copy workspace:techsupport/ filename.tar {scp | ftp }: user_name@IP_address Enter username’s password: password	Copies the output file to an external location through SCP or FTP. The SCP and FTP commands require an absolute path for the target location. The path to your home directory cannot include special symbols, such as ‘~’.

Verification of LDAP Configurations

Note	This procedure can be performed only through the Cisco UCS Manager CLI.

The Cisco UCS Manager CLI test commands verify the configuration of the Lightweight Directory Access Protocol (LDAP) provider or the LDAP provider group.

Verifying the LDAP Provider Configuration

Note

The test aaa server ldap command verifies the server-specific configuration, irrespective of the LDAP global configurations. This command uses the values for the base DN, filter, attribute, and timeout that are configured at the LDAP provider level. If the base DN or filter at the provider level is empty, the LDAP search fails.

You can enter the test aaa server ldap command to verify the following information if Cisco UCS Manager is able to communicate with the LDAP provider as follows:

• The server responds to the authentication request if the correct username and password is provided.

• The roles and locales defined on the user object in the LDAP are downloaded.

• If the LDAP group authorization is turned on, the LDAP groups are downloaded.

Procedure

	Command or Action	Purpose
Step 1	connect nxos	Enters nxos mode.
Step 2	test aaa server ldap	Tests the LDAP provider configuration.

Example

The following is an example of the response:

UCS-A# /security # connect nxos 
UCS-A#(nxos)# test aaa server ldap 10.193.23.84 kjohn Nbv12345
user has been authenticated
Attributes downloaded from remote server:
User Groups:
CN=g3,CN=Users,DC=ucsm  CN=g2,CN=Users,DC=ucsm  CN=group-2,CN=groups,DC=ucsm  
CN=group-1,CN=groups,DC=ucsm  CN=Domain Admins,CN=Users,DC=ucsm
CN=Enterprise Admins,CN=Users,DC=ucsm  CN=g1,CN=Users,DC=ucsm  
CN=Administrators,CN=Builtin,DC=ucsm
User profile attribute:
shell:roles="server-security,power"
shell:locales="L1,abc"
Roles:
server-security power
Locales:
L1 abc

Verifying the LDAP Provider Group Configuration

Note	The test aaa group command verifies the group-specific configuration, irrespective of the LDAP global configurations.

You can enter the test aaa group command to verify the following information if Cisco UCS Manager is able to communicate with the LDAP group as follows:

• The server responds to the authentication request if the correct username and password is provided.

• The roles and locales defined on the user object in the LDAP are downloaded.

• If the LDAP group authorization is turned on, the LDAP groups are downloaded.

Procedure

	Command or Action	Purpose
Step 1	connect nxos	Enters nxos mode.
Step 2	test aaa group	Tests the LDAP group configuration.

Example

The following is an example of the response:

UCS-A# /security # connect nxos
UCS-A#(nxos)# test aaa group grp-ad1 kjohn Nbv12345
user has been authenticated
Attributes downloaded from remote server:
User Groups:
CN=g3,CN=Users,DC=ucsm  CN=g2,CN=Users,DC=ucsm  CN=group-2,CN=groups,DC=ucsm  
CN=group-1,CN=groups,DC=ucsm  CN=Domain Admins,CN=Users,DC=ucsm
CN=Enterprise Admins,CN=Users,DC=ucsm  CN=g1,CN=Users,DC=ucsm  
CN=Administrators,CN=Builtin,DC=ucsm
User profile attribute:
shell:roles="server-security,power"
shell:locales="L1,abc"
Roles: 
server-security power
Locales:
L1 abc

В продолжение поста о распаковке Cisco UCS, приехавшей в наш Центр компетенции, мы расскажем о Cisco UCS Manager, с помощью которого производится настройка всей системы. Данную задачу мы выполнили в рамках подготовки к тестированию FlexPod (Cisco UCS + NetApp в режиме MetroCluster) для одного из наших заказчиков.

Отметим основные преимущества Cisco UCS, благодаря которым выбор пал именно на данную систему:

• Cisco UCS является унифицированной системой, а не разрозненной группой серверов с попыткой единого
  управления;
• наличие унифицированной фабрики, которая содержит встраиваемое управление, использование универсального
  транспорта, отсутствие уровня коммутации в шасси и на уровне гипервизора– Virtual Interface Card, простое
  каблирование;
• единая конвергентная фабрика на всю систему (единовременное управление до 320 серверами) в отличие от
  конкурентов – своя фабрика на каждое шасси (до 16 серверов);
• одна точка управления, быстрота конфигурирования при использовании политик и профилей, что дает минимизацию
  рисков при настройке, развертывании, тиражировании, обеспечивает высокую масштабируемость.

Традиционные блейд системы имеют следующие недостатки:

• каждый блейд-сервер – идеологически, с точки зрения управления такой же стоечный или башенный сервер, только
  в другом форм-факторе;
• каждый сервер – сложная система с большим числом компонентов и большим числом мощных средств управления;
• каждое шасси, каждый сервер, и в большинстве случаев каждый коммутатор должны настраиваться отдельно и чаще
  всего «вручную»;
• «зонтичные» «единые» системы управления существуют, но это в большинстве случаев просто набор ссылок на
  отдельные утилиты;
• интеграция «наверх» у этих систем возможна, но ограничивается «стандартными» простыми интерфейсами.

В отличие от конкурентов Cisco UCS имеет продуманную систему управления – UCS Manager. Данный продукт имеет следующие отличительные особенности:

• не требует отдельного сервера, СУБД, ОС и лицензий на них — он часть UCS;
• не требует инсталляции и настройки – просто включите систему и задайте IP-адрес;
• обладает встроенной отказоустойчивостью;
• имеет эффективные и простые средства резервного копирования конфигурации;
• обновляется несколькими «кликами»;
• делегирует весь свой функционал «наверх» через открытый XML API;
• стоит $0.00.

Сам Cisco UCS Manager располагается на обоих Fabric Interconnect, и, соответственно, все настройки, политики и т.п. хранятся также на них.

К одной паре Fabric Interconnect может подключено до 20 блейд-шасси. Управление каждым из шасси осуществляется из одной точки – UCS Manager. Это возможно благодаря тому, что Fabric Interconnect строится как распределенный коммутатор с участием Fabric Extender’ов . Каждое шасси имеет по два Fabric Extender, с возможностью подключения 4 либо 8 10GB линками каждый.

Начинаем с самого основного: подключения консольного провода и задания начального IP-адреса.
После чего запускаем браузер и соединяемся. (Понадобится java, т.к. по сути GUI UCS Manager’а реализовано на ней). На рисунках ниже представлен внешний вид программы, который появляется на экране после ввода логина и пароля и входа в UCS Manager.

Работу по настройке начинаем на вкладке «LAN». Надо отметить, что с настройки данной вкладки, а также вкладки «SAN» начинается настройка всей системы. Особенно актуально это в случае использования бездисковых серверов – как раз наш случай.

Здесь настраивается абсолютно все, что имеет отношение к сети: какие VLAN разрешены на том или ином Fabric Interconnect, какими портами соединены Fabric Interconnect между собой, какие порты в каком режиме работают и многое другое.

Также на этой вкладке настраиваются шаблоны для виртуальных сетевых интерфейсов: vNIC, которые в дальнейшем будут применяться в сервисных политиках, описанных выше. На каждый vNIC (которых к слову на хосте может быть до 512 при установке 2 плат Cisco UCS VIC) привязывается определенный VLAN, либо группа VLAN и «общение» физического хоста по сети идет именно через эти vNIC.

Организация такого количества vNIC возможна с помощью карты виртуального интерфейса VIC (Virtual Interface Card). В семействе блейд серверов Cisco UCS существует 2 вида VIC: 1240 и 1280.

Каждая из них имеет возможность поддержки до 256 vNIC или vHBA. Главное отличие в том, что 1240 является LOM модулем, а 1280 мезанинная карта, так же в пропускной способности.

1240 самостоятельно имеет возможность агрегации до 40 GB, с возможностью расширения до 80GB при использовании Expander Card.

1280 изначально умеет пропускать через себя до 80GB.

VIC позволяют динамически назначать пропускную способность на каждый vNIC или vHBА, а так же поддерживают hardware failover.

Ниже можно заметить несколько созданных пулов IP адресов, из которых эти самые адреса будут присваиваться сетевым интерфейсам в определенных VLAN (этакий аналог EBIPA у HP). Аналогично дело обстоит и с MAC адресами, которые берутся из MAC пулов.

В общем концепция простая: создаем VLAN(ы), настраиваем порты на Fabric Interconnect, настраиваем vNIC, выдаем этим vNIC MAC/IP адреса из пулов и загоняем в сервисную политику для дальнейшего использования.

Важное замечание: Как вы знаете существуют валидированные дизайны Cisco с крупными игроками рынка систем хранения данных, например, такой как FlexPod. Дизайн FlexPod включает серверное и сетевое оборудование – Cisco, а в роли СХД выступает NetApp. Зачем спросите вы там еще и сетевое оборудование? Дело все в том, что в версии 1.4 и 2.0 UCS Manager сам Fabric Interconnect не осуществлял FC зонирование. Для этого был необходим вышестоящий коммутатор (например, Cisco Nexus), подключенный к Fabric Interconnect через Uplink порты. В версии UCS Manager 2.1. появилась поддержка локальных зон, что дало возможно подключать Storage напрямую к Fabric Interconnect. Возможные дизайны можно посмотреть вот здесь. Но все-таки оставлять FlexPod без коммутатора не стоит, т.к. FlexPod является самостоятельным строительным блоком ЦОДа.

Перейдем к следующей вкладке: «SAN».

Здесь располагается все, что относится к сети передачи данных: iSCSI и FCoE. Концепция такая же, как и у сетевых адаптеров vNIC, но со своими отличиями: WWN, WWPN, IQN и т.п.

Переходим на вкладку «Equipment».

С помощью данного интерфейса можно увидеть информацию о нашей общей вычислительной инфраструктуре, которая была развернута для тестирования. Так, было задействовано одно шасси (Chassis 1) и четыре сервера-лезвия (Server1, Server2, Server3, Server4). Эту информацию можно получить из дерева в левой части (Equipment), либо в графическом виде (Physical Display).

Помимо количества шасси/серверов можно посмотреть информацию о вспомогательных компонентах (вентиляторы, блоки питания и т.п.), а также информацию об алертах разного типа. Общее количество алертов выводится в блоке «Fault Summary», отдельно информацию по каждому узлу можно посмотреть, кликнув по нему слева. Цветные рамки вокруг названий узлов слева помогают узнать, на каком узле есть алерты. Внимательные читатели заметят также небольшие пиктограммы и на графическом виде.

Наши Fabric Interconnect настроены на работу в failover режиме (при выходе из строя одного из агрегатов – его работу незамедлительно возьмет на себя другой). Информация об этом видна в самом низу дерева – обозначения primary и subordinate.

Далее переходим к вкладке «Servers».

Здесь находятся различные политики, шаблоны сервисных профилей и непосредственно сами сервисные профили. Например, мы можем создать несколько организаций, каждой из которых назначить свои политики выбора загрузочного устройства, доступа к определенным VLAN/VSAN и др.

На следующем рисунке показан пример настройки iSCSI загрузочного луна.

Глобальный смысл всего этого: предварительно настроив все политики и шаблоны, можно быстро настраивать новые сервера для работы, применяя тот или иной сервисный профиль (Service Profile).

Сервисный профиль, который содержит в себе вышеупомянутые настройки, может быть применен к одному определенному серверу, либо группе серверов. Если в ходе развертывания возникают какие-либо ошибки или сообщения – мы можем посмотреть их в соответствующей вкладке «Faults»:

После чего пользователи этих организаций могут развернуть и настроить сервер под себя с выбранной операционной системой и набором предустановленным набором программного обеспечения. Для этого необходимо воспользоваться возможностями интерфейса UCS Manager, либо обратившись к автоматизации: например при помощи продукта VMware vCloud Automation Center или Cisco Cloupia.

Переходим на вкладку «VM».

В VMware vCenter можно установить плагины для Cisco UCS Manager. Так, мы подключили плагин, через который подключили виртуальный дата-центр с названием «FlexPod_DC_1». В нем работает Cisco Nexus 1000v (nexus-dvs), и мы имеем возможность смотреть его настройки.

Ну и последняя вкладка: «Admin».

Здесь мы можем посмотреть глобальные события: ошибки, предупреждения. Собрать различные данные в случае обращения в поддержку Cisco TAC и т.п. вещи. В частности их можно получить на вкладках «TechSupport Files», «Core Files».

На скриншоте видны ошибки, связанные с отключением электричества. В рамках тестирования мы отключали по очереди блоки питания (Power supply 1 in fabric interconnect A, B) для демонстрации заказчику стабильности работы системы при смоделированном случае отключения подачи питания на одном энерговводе.

В качестве заключения хотим отметить, что весь процесс настройки и тестирования FlexPod, частью которого является настройка и тест Cisco UCS, занял целую неделю. Немного усложнило задачу отсутствие документации для последней версии UCS Manager 2.1. Приходилось пользоваться вариантом для 2.0, который имеет ряд расхождений. На всякий случай выкладываем ссылку на документацию. Возможно, и она кому-нибудь пригодится.

В следующих постах мы продолжим освещать тему FlexPod. В частности мы планируем рассказать о том, как мы вместе с заказчиком тестировали NetApp в режиме MetroCluster в составе FlexPod. Не отключайтесь!

В этой небольшой статье я хочу показать самые распространённые типы ошибок, возникающие на сетевом интерфейсе коммутатора или роутера. Это будет полезно при проведении диагностики и аудита локальной сети среднего и крупного масштаба.

Align-Err
Количество ошибок выравнивания.
Как правило, увеличение данного счетчика свидетельствует о проблемах согласования дуплексных режимов, либо о наличии проблемы на физическом уровне.

collisions
Число коллизий произошедших до окончания передачи пакета. Нормальное явление для полудуплексного интерфейса. Быстрый рост счетчика может быть вызван высокой загрузкой интерфейса, либо несоответствием режимов дуплекса.

CRC
Несовпадение контрольной суммы кадра.
Обычно является результатом конфликтов, но может указывать и на физическую неполадку. В некоторых случаях возможны наводки на физику ЛВС, либо помехи.

Pause input
Подключенное устройство запрашивает приостановку передачи трафика при переполнении его буфера.

Excess-Col
Подобно коллизиям не должно наблюдаться на полнодуплексном интерфейсе.

FCS-Err
Ошибки в контрольной последовательности кадров.
Как правило, увеличение данного счетчика свидетельствует о проблемах согласования дуплексных режимов, либо о наличии проблемы на физическом уровне.

Ignored
Может быть признаком широковещательного шторма в сети.

Late-Col
Коллизии на последних этапах передачи кадра. Не должны наблюдаться на полнодуплексном порту.

Lost carrier
Потеря несущей. Проблемы на физическом уровне.

Underruns
Скорость передатчика превышает возможности коммутатора.

Undersize
Полученные кадры с размером меньше минимума. Необходимо проверить устройство, посылающее такие кадры

Cisco Unified Computing System (UCS) — это платформа для ЦОД следующего поколения, которая объединяет вычислительные и сетевые ресурсы, доступ к системам хранения данных, а также средства виртуализации в единую систему. Решение позволяет значительно снизить затраты на эксплуатацию ЦОД и увеличивает операционную эффективность бизнеса. 

Система объединяет в себе универсальную высокоскоростную сетевую инфраструктуру (unified fabric) на базе технологий 10-Gigabit Ethernet и широко используемую x-86 архитектуру серверов компании Intel. Решение Cisco UCS позволяет создать интегрированную и масштабируемую платформу, в которой все элементы решения управляются централизовано.  

Cisco UCS имеет в своем составе единую систему управления, которая позволяет управлять комплексами до 160 физических серверов, на каждом из которых могут функционировать десятки виртуальных машин, обеспечивая превосходное масштабирование ЦОД без увеличения сложности управления.

Архитектура системы Cisco UCS улучшает переносимость профилей физических машин, т.к. профиль сервера, конфигурация его LAN/SAN соединений и I/O, встроенного ПО и профили сетевых соединений могут быть динамически присвоены любому физическому серверу в системе. Такая высокодинамичная среда с поддержкой принципа Stateless Computing может быть легко адаптирована для удовлетворения быстро меняющихся требований современных центров обработки данных. Это подразумевает внедрение в нужный момент необходимых вычислительных ресурсов и перемещение рабочей нагрузки.

Cisco Unified Computing System улучшает доступность, безопасность и производительность благодаря интегрированному дизайну системы.

Компоненты системы UCS 

•          Центральные коммутаторы UCS 6200 Series Fabric 

•          Шассиблейд—серверов UCS 5100 Series 

•          Сетевыемодули UCS 2200 Series Fabric Extender 

•          Блейд—серверы UCS B-Series 

•          Стоечные-серверы UCSC—Series 

•          Сетевые адаптеры UCS 

•          Модуль управления UCS Manager 

Центральные коммутаторы UCS серии 6200 Fabric Interconnect 

Конвергентные коммутаторы сочетают функции коммутации трафика ethernet и fibre channel с управлением системой UCS. Архитектура коммутаторов предусматривает коммутацию трафика на скоростях до 10 Гбит/с без потерь пакетов и с крайне низкими задержками. Устройства поставляются в корпусе 1RU с 48 портами или в корпусе 2RU с 96 портами. Поддерживают модули расширения, обеспечивающие подключения Fibre Channel и 10 Gigabit Ethernet.  

Основные функции:  

•        10 Gigabit Ethernet порты SFP+, поддержка FCoE  
•        Варианты 48 и 96 встроенных портов со слотами расширения для добавления портов Fibre Channel и 10 GE 
•        Встроенная система управления UCS Manager 
•        До 1.04 Tbps производительности 
•        Зарезервированные блоки питания и вентиляторы с «горячей заменой» 
•        Управление до 40 шасси на систему UCS

Сетевоймодуль UCS серии 2200 Fabric Extender 

              Модули обеспечивают связи между центральными коммутаторами и блейд-серверами. С их помощью упрощаются процессы диагностики, подключения кабелей и управления системой. 

Основные функции: 

Шасси для блейд-серверов UCS серии 5100

Представляет собой серверную корзину, которая поддерживает до восьми блейд-серверов и до двух сетевых модулей в корпусе 6RU, не требуя дополнительных модулей управления. 

Основные функции: 

•        4 блока питания (резервирование по схеме N+1 или N+N )
•        8 вентиляторов (по умолчанию) 
•        Охлаждение «спереди назад» 
•        Высота шасси 6U  
•        Внутрь можно установить до 8 блейд-серверов половинной ширины или 4 блейд-сервера полной ширины 
•        Все блейд-серверы одинарной высоты 
•        Установка до 2-х сетевых модулей 
•        Индикаторная идентификация 

Блейд-серверы UCS (серия B) 

Блейд-серверы UCS – это блейд-серверы архитектуры x86 на базе процессоров Intel Xeon, которые адаптируются под требования приложений, регулируют использование электроэнергии и обеспечивают лучшую виртуализацию среди устройств своего класса. Уникальная технология расширения памяти Cisco значительно увеличивает объем памяти, что повышает производительность и пропускную способность для ресурсоемких приложений виртуализации и обработки крупных наборов данных. Кроме того, эта технология предлагает более экономичный вариант памяти для менее требовательных рабочих нагрузок.

Стоечные серверы UCS (серия C)

Стоечные серверы UCS — серверы, предназначенные для работы в автономных средах и в составе среды унифицированных вычислений Cisco, выполненные в стандартном конструктивном исполнении. Они поддерживает модель пошагового развертывания с возможностью будущего перехода на унифицированные вычисления.

Сетевые адаптеры Cisco UCS

В настоящее время все сетевые адаптеры для блейд-систем условно можно поделить на три типа: традиционные, конвергентные и виртуализиро-ванные. 

•            Традиционные адаптеры — классические адаптеры с аппаратной поддержкой протокола Ethernet и программной поддержкой конвергентного протокола Fibre Channel over Ethernet, предназначенные для передачи и обмена данными в сети. Наиболее известный производитель таких адаптеров — компания Intel, Broadcom. 

•            Конвергентные адаптеры — адаптеры с интегрированными чипами протоколов 10GbE и Fibre Channel или имеющие конвергентный чип протокола FCoE. На данный момент это наиболее используемый тип адаптеров в существующих серверных системах. Наиболее распространенные производители этих типов — компании Emulex и Qlogic. 

•            Виртуализированные адаптеры – адаптеры, которые позволяют создать несколько логических адаптеров как в динамике (например, при интеграции с системами виртуализации), так и статично. Использование виртуализированного адаптера в среде гипервизора позволяет перенести задачи коммутации трафика между сетевыми машинами на сетевое оборудование, что позволяет высвободить процессорные ресурсы и предоставить их виртуальным машинам, тем самым повысить их производительность в целом.  

Компания Cisco Systems разработала собственный виртуализированный двухпортовый конвергентный адаптер Cisco Virtualized Interface Card с исключительными характеристиками, позволяющий иметь преимущество перед другими производителями:

•            Способен создать до 58 виртуализированных Ethernet или FC адаптеров (на одном физическом адаптере с использованием метки VNTag проекта стандарта IEEE 802.1Qbh) 
•            Поддержка стандарта PCIe 
•            Работа в виртуализированной и невиртуализированной среде 
•            Поддержка Hypervisor Bypass 
•            Отказоустойчивость на аппаратном уровне 
•            Высокая производительность (2x 10Gb, >600K IOPS) 

В стоечных серверах UCS используются наиболее востребованные сетевые адаптеры в виде карт PCIe, таких производителей, как QLogic, Broadcom, Emulex и Intel, а также виртуализированный PCIe адаптер Cisco VIC.

Программный модуль UCS manager

UCS Manager – это встроенный программный модуль, с помощью которого осуществляется управление всеми компонентами блейд-системы. Интерфейс UCS Manager разделен на пять зон: администрирование, оборудование, серверы, ЛВС и сеть хранения. Под администрированием подразумеваются операции, производимые с помощью UCS Manager. Оборудование — это, как правило, задействованная в данный момент физическая основа UCS. Серверами в общем случае именуются логические серверы, созданные и используемые посредством UCS Manager. В зону ЛВС включается всё, что относится к локальным сетям, а в зону сети хранения — всё, что касается ресурсов хранения.

Преимущества Unified Computing System (UCS)

•        Встроенное управление системой

Каждый из компонентов объединенной системы вычислений Cisco UCS поставляется со встроенным микропрограммным обеспечением, которое позволяет управлять работой устройства с помощью Cisco UCS Manager. Администраторы сети, системы хранения данных и серверов могут работать с графическим пользовательским интерфейсом или интерфейсом командной строки системы Cisco UCS Manager или, используя документированный набор функций XML API, из существующей корпоративной системы управления ЦОД.

Ролевая модель контроля упрощает решение задач управления, к которым должны привлекаться группы администраторов серверов, сети и системы хранения данных, позволяя ограничить область распространения специальной информации рамками каждой группы. Это позволят экспертам по конкретным вопросам следовать обычным рабочим процедурам и интегрировать все данные о конфигурации в рамках единой системы управления, а не в разрозненных системах, как это нередко происходит в современных ЦОД.

•        Внедрение приложений с использованием сервисных профилей

ПО UCS Manager реализует концепцию управления на базе ролей и политик с использованием сервисных профилей и шаблонов. Информация о параметрах системы электропитания, охлаждения, физической безопасности, а также о состоянии оборудования, конфигурации сетевой среды и сети хранения данных содержится в сервисном профиле. Использование сервисных профилей позволяет ИТ-персоналу ЦОД снизить время внедрения приложений в ЦОД от дней до минут.

•        Объединенный транспорт

Разработанная CiscoSystems технология консолидированной сети (unifiedfabric) на базе наборов стандартов DataCenterBridging и FibreChanneloverEthernet (FCoE) позволяет значительно снизить затраты на элементы сетевой инфраструктуры (множество сетевых адаптеров, коммутаторы LAN, SAN, различные сетевые кабели и т.п.). Сетевые модули шасси позволяют отказаться от использования коммутаторов в составе блейд-серверов путем транзита всего трафика от серверов через централизованную фабрику коммутации, где трафик будет обрабатываться и коммутироваться по назначению. Унифицированная фабрика коммутации строится на базе технологии 10-Gigabit Ethernet со стандартными кабельными соединениями. Теперь в случае изменения типа подключения сервера к сети нет необходимости в установке дополнительных адаптеров и прокладке новых кабелей.

•        Поддержка технологии виртуализации (VN-Link)

Технология Cisco VN-Link расширяет границу сети до виртуальной машины. Эта технология стирает различия по управлению сетевой инфраструктурой для физических и виртуальных серверов. Теперь все сетевые соединения настраиваются и управляются централизовано, без выделения дополнительного уровня коммутации для виртуальных сред. Конфигурации портов ввода/вывода и сетевые политики могут перемещаться между виртуальными серверами, что увеличивает эффективность и уменьшает сложность их эксплуатации.

•        Виртуализированный адаптер Cisco VIC

          Виртуализированный адаптер Cisco VIC позволяет получить на одномдвухпортовом конвергентном адаптере динамически или статически до 58 виртуальных адаптеров, каждый их которых представлен PCIe-функцией. Таким образом, операционная система «видит» каждый из виртуальных адаптеров как физический адаптер. Данным виртуальным адаптерам можно гарантировать полосу пропускания; неиспользуемая в текущий момент часть полосы пропускания любого виртуального адаптера может быть динамически распределена между другими виртуальными адаптерами, которым в тот же момент требуется бОльшая полоса, чем им гарантировал системный администратор.

•        Технология расширения памяти Cisco

Технология расширения памяти Cisco позволяет увеличить в 4 раза количество разъемов для установки модулей памяти DIMM (до 96) по сравнению с классическими двухпроцессорными серверами архитектуры x86 при сохранении скорости частоты 1866Мгц. Увеличение оперативной памяти позволяет увеличить производительность работы серверов, особенно при работе в виртуальных средах.

•        Современная производительность

В решении Cisco UCS используются блейд-сервера, построенные на базе процессоров серии Intel Xeon E5 v2 и Е7 v2. Эти многоядерные процессоры интеллектуально и автоматически регулируют производительность серверов в соответствии с требованиями приложений, увеличивают производительность в необходимый момент и существенно экономят энергопотребление в период простоя. Для более точного управления серверами все параметры производительности и экономии электроэнергии могут быть настроены вручную.

•        Энергетическая эффективность

Компоненты решения Cisco UCS были спроектированы с учетом требований по энергетической эффективности. Упрощенная архитектура системы позволила сократить количество элементов, для которых необходимо электропитание и охлаждение примерно на 50% по сравнению с классическими средами блейд-серверов. Шасси блейд-серверов в решении Cisco UCS сделано таким образом, чтобы значительно увеличить теплообмен с окружающей средой. Решение Cisco UCS использует новые, более эффективные блоки питания для своих компонентов.

Гарантия и сервисные контракты

Компания Cisco Systems на все продукты UCS помимо стандартной гарантии по желанию партнеров предоставляет сервисные контракты.

Unified Computing Warranty (3-year) — бесплатная стандартная гарантия сроком на 3 года, она включает в себя:

•          Загрузку прошивок BIOS и драйверов
•          Авансовую замену оборудования сроком NBD (next business day)
•          90-дневную гарантию на программный носитель
•          Круглосуточный доступ в службу технической поддержки Cisco TAC для оформления RMA

Unified Computing Warranty Plus — платное расширение гарантии сроком на 1 год (по умолчанию) включает:

•          Все выше перечисленное
•          Более гибкое время реакции на замену оборудования • Возможность замены оборудования на площадке у заказчика

 Unified Computing Support Service — платный сервисный контракт сроком на 1 год (по умолчанию), включает:

•          Все выше перечисленное
•          Круглосуточная поддержка в TAC на ПО (все ОС, VMWare, BMC BladeLogic)
•          Разделение зоны ответственности между Cisco и производителем ПО
•          Возможность проактивной диагностики оборудования
•          Круглосуточный доступ в службу Cisco TAC по любым вопросам
•          Обновление UCS Manager

ucs_cisco@marvel.ru

Компания Марвел: +7 812 326 3232; +7 495 745 8008, www.marvel.ru

Intel, логотип Intel,Xeon и Xeon Inside являются товарными знаками корпорации Intel на территории США и других стран.