Estos contenidos se han traducido de forma automática para su comodidad, pero Huawei Cloud no garantiza la exactitud de estos. Para consultar los contenidos originales, acceda a la versión en inglés.
Cómputo
Elastic Cloud Server
Bare Metal Server
Auto Scaling
Image Management Service
Dedicated Host
FunctionGraph
Cloud Phone Host
Huawei Cloud EulerOS
Redes
Virtual Private Cloud
Elastic IP
Elastic Load Balance
NAT Gateway
Direct Connect
Virtual Private Network
VPC Endpoint
Cloud Connect
Enterprise Router
Enterprise Switch
Global Accelerator
Gestión y gobernanza
Cloud Eye
Identity and Access Management
Cloud Trace Service
Resource Formation Service
Tag Management Service
Log Tank Service
Config
Resource Access Manager
Simple Message Notification
Application Performance Management
Application Operations Management
Organizations
Optimization Advisor
Cloud Operations Center
Resource Governance Center
Migración
Server Migration Service
Object Storage Migration Service
Cloud Data Migration
Migration Center
Cloud Ecosystem
KooGallery
Partner Center
User Support
My Account
Billing Center
Cost Center
Resource Center
Enterprise Management
Service Tickets
HUAWEI CLOUD (International) FAQs
ICP Filing
Support Plans
My Credentials
Customer Operation Capabilities
Partner Support Plans
Professional Services
Análisis
MapReduce Service
Data Lake Insight
CloudTable Service
Cloud Search Service
Data Lake Visualization
Data Ingestion Service
GaussDB(DWS)
DataArts Studio
IoT
IoT Device Access
Otros
Product Pricing Details
System Permissions
Console Quick Start
Common FAQs
Instructions for Associating with a HUAWEI CLOUD Partner
Message Center
Seguridad y cumplimiento
Security Technologies and Applications
Web Application Firewall
Host Security Service
Cloud Firewall
SecMaster
Data Encryption Workshop
Database Security Service
Cloud Bastion Host
Data Security Center
Cloud Certificate Manager
Blockchain
Blockchain Service
Servicios multimedia
Media Processing Center
Video On Demand
Live
SparkRTC
Almacenamiento
Object Storage Service
Elastic Volume Service
Cloud Backup and Recovery
Storage Disaster Recovery Service
Scalable File Service
Volume Backup Service
Cloud Server Backup Service
Data Express Service
Dedicated Distributed Storage Service
Contenedores
Cloud Container Engine
SoftWare Repository for Container
Application Service Mesh
Ubiquitous Cloud Native Service
Cloud Container Instance
Bases de datos
Relational Database Service
Document Database Service
Data Admin Service
Data Replication Service
GeminiDB
GaussDB
Distributed Database Middleware
Database and Application Migration UGO
TaurusDB
Middleware
Distributed Cache Service
API Gateway
Distributed Message Service for Kafka
Distributed Message Service for RabbitMQ
Distributed Message Service for RocketMQ
Cloud Service Engine
EventGrid
Dedicated Cloud
Dedicated Computing Cluster
Aplicaciones empresariales
ROMA Connect
Message & SMS
Domain Name Service
Edge Data Center Management
Meeting
AI
Face Recognition Service
Graph Engine Service
Content Moderation
Image Recognition
Data Lake Factory
Optical Character Recognition
ModelArts
ImageSearch
Conversational Bot Service
Speech Interaction Service
Huawei HiLens
Developer Tools
SDK Developer Guide
API Request Signing Guide
Terraform
Koo Command Line Interface
Distribución de contenido y cómputo de borde
Content Delivery Network
Intelligent EdgeFabric
CloudPond
Soluciones
SAP Cloud
High Performance Computing
Servicios para desarrolladores
ServiceStage
CodeArts
CodeArts PerfTest
CodeArts Req
CodeArts Pipeline
CodeArts Build
CodeArts Deploy
CodeArts Artifact
CodeArts TestPlan
CodeArts Check
Cloud Application Engine
aPaaS MacroVerse
KooPhone
KooDrive

Configuración de racks para hosts

Actualización más reciente 2023-11-20 GMT+08:00

Escenario

Todos los hosts de un clúster grande generalmente se despliegan en varios racks. Los hosts en diferentes racks se comunican entre sí a través de switches. El ancho de banda de red entre diferentes hosts en el mismo rack es mucho mayor que el de diferentes racks. En este caso, planifique la topología de red basándose en los siguientes requisitos:

  • Para mejorar la velocidad de comunicación, se recomienda intercambiar datos entre hosts en el mismo rack.
  • Para mejorar la capacidad de tolerancia a fallas, distribuya procesos o datos de servicios distribuidos en diferentes hosts de múltiples racks de la manera más dispersa posible.

Hadoop utiliza una estructura de directorios de archivos para representar hosts.

El HDFS no puede determinar automáticamente la topología de red de cada DataNode del clúster. Debe establecer el nombre del rack para identificar el rack donde se encuentra el host para que el NameNode pueda dibujar la topología de red de los DataNodes requeridos y realizar copias de respaldo de los datos de los DataNodes en diferentes racks. Del mismo modo, YARN necesita obtener información de rack y asignar tareas a diferentes NodeManagers según sea necesario.

Si cambia la topología de la red del clúster, debe reasignar racks para hosts en FusionInsight Manager para que los servicios relacionados se puedan ajustar automáticamente.

Impacto en el sistema

Si se cambia el nombre del rack host, la política de almacenamiento para las réplicas de HDFS, la asignación de tareas de YARN y la ubicación de almacenamiento de las particiones de Kafka se verán afectadas. Después de la modificación, debe reiniciar HDFS, YARN y Kafka para que la configuración surta efecto.

La configuración inadecuada del rack desequilibra las cargas (incluidas la CPU, la memoria, el disco y la red) entre los nodos del clúster, lo que reduce la confiabilidad y la estabilidad del clúster. Por lo tanto, antes de asignar los bastidores, tenga en cuenta todos los aspectos y establezca correctamente racks.

Políticas de asignación de racks

NOTA:

Rack físico: indica el rack real donde reside el host.

Rack lógico: indica el nombre del rack del host en FusionInsight Manager.

Política 1: Cada rack lógico tiene casi el mismo número de hosts.

Política 2: El nombre del rack lógico del host debe cumplir con el del rack físico al que pertenece el host.

Política 3: Si solo hay pocos hosts en un rack físico, combine este rack físico y otros racks físicos con pocos hosts en un rack lógico, que cumpla con la política 1. Los hosts de dos salas de equipos no se pueden colocar en un rack lógico. De lo contrario, pueden producirse problemas de rendimiento.

Política 4: Si hay muchos hosts en un rack físico, divida estos hosts en varios racks lógicos, lo que cumple con la política 1. Los hosts con grandes diferencias no deben colocarse en el mismo rack lógico. De lo contrario, se reducirá la confiabilidad del clúster.

Política 5: Se recomienda establecer default u otros valores para racks lógicos en la primera capa, y los valores en el mismo clúster deben ser coherentes.

Política 6: El número de hosts en cada rack no puede ser inferior a 3.

Política 7: Un clúster puede contener como máximo 50 racks lógicos. Si hay demasiados racks lógicos en un clúster, el mantenimiento es difícil.

Prácticas recomendadas

Por ejemplo, en un clúster, 100 hosts están situados en dos salas de equipos A y B. A tiene 40 hosts y B tiene 60 hosts. En la sala A, hay 11 hosts en Ra1 de rack físico y 29 hosts en Ra2 de rack físico. En la sala B, hay seis hosts en el rack físico Rb1, 33 hosts en el rack físico Rb2, 18 hosts en el rack físico Rb3 y tres hosts en el rack físico Rb4.

De acuerdo con la política de asignación de rack, cada rack lógico contiene casi el mismo número (por ejemplo, 20) de hosts. Los detalles de la asignación son los siguientes:

  • Rack lógico /default/racka1: 11 hosts en Ra1 de rack físico y nueve hosts en Ra2 de rack físico
  • Rack lógico /default/racka2: los 20 hosts restantes (excepto los nueve hosts del rack lógico /default/racka1) en el rack físico Ra2
  • Rack lógico /default/rackb1: seis hosts en rack físico Rb1 y 13 hosts en rack físico Rb2
  • Rack lógico /default/rackb2: los 20 hosts restantes en el rack físico Rb2
  • Rack lógico /default/rackb3:18 hosts en rack físico Rb3 y tres hosts en rack físico Rb4

Ejemplo de asignación de racks:

Procedimiento

  1. Inicie sesión en FusionInsight Manager.
  2. Haga clic en Hosts.
  3. Seleccione el cuadro de verificación del host de destino.
  4. Seleccione Set Rack en la lista desplegable More.

    • Establezca los nombres de rack en jerarquía según la topología de red real. Separe racks de diferentes capas usando barras inclinadas (/).
    • Las reglas de nomenclatura de rack son las siguientes:/level1/level2/... El número de niveles debe ser al menos 1, y el nombre no puede estar vacío. Un rack puede contener letras, dígitos y guiones bajos (_) y no puede superar los 200 caracteres.

      Por ejemplo, /default/rack0.

    • Si los hosts del rack que se van a modificar contienen instancias de DataNode, asegúrese de que los niveles de nombre de rack de los hosts donde residen todas las instancias de DataNode son los mismos. De lo contrario, la configuración no se entrega.

  5. Haga clic en OK.

Utilizamos cookies para mejorar nuestro sitio y tu experiencia. Al continuar navegando en nuestro sitio, tú aceptas nuestra política de cookies. Descubre más

Comentarios

Comentarios

Comentarios

0/500

Seleccionar contenido

Enviar el contenido seleccionado con los comentarios