Ceph Meetup
•Descargar como PPTX, PDF•
0 recomendaciones•76 vistas
Ceph Meetup from Abril 2019
Recomendados
Más contenido relacionado
Similar a Ceph Meetup
Similar a Ceph Meetup (20)
Más de Alvaro Soto
Último
Último (20)
Ceph Meetup
- 2. CEPH-101 Álvaro Soto - 2019 Cloud Infrastructure Engineer @ Sentinel.la
- 3. Ceph Es una plataforma de almacenamiento definida por software, masivamente escalable (no tiene límite teórico) y sin ningún punto de fallo (en los componentes de software). Actualmente puede entregar servicios de almacenamiento usando distintas formas, bloques, objetos, sistema de archivos.
- 4. Características ● Escalabilidad. ● Commodity Hardware. ● Auto-administrable. ● No tiene un único punto de fallo. ● OpenSource.
- 5. Versiones
- 6. Arquitectura
- 7. OSD
- 8. Cluster
- 9. Monitores ● Anillo de alta disponibilidad. ● Consenso usando PAXOS. ● Información del estado del cluster. ● Mapas de información (cluster, osd)
- 10. Manager ● Monitoreo interno todo en un solo lugar ● Conección con herramientas de monitoreo externo ○ RESTful plugin ○ Zabbix plugin ○ Prometheus plugin ○ Influx plugin ○ ….. http://docs.ceph.com/docs/mimic/mgr/
- 12. Cosas/Terminos Importantes ● Pools ● Placement groups ● CRUSH OBJ OBJ OBJ | / | / | OSD <-------- OSD <-------- | PG #1 --------> Pool OSD <-------- /
- 16. Consideraciones para implementar, un lab? ● Requerimientos mínimos ○ 3 monitores ○ 3 nodos OSD ○ 1 disco por nodo de OSD ● Método de instalación ○ Ceph-ansible ■ Verificar que versión de ceph se va a instalar para conocer la versión necesaria de ceph-ansible y de ansible.
- 17. Consideraciones para implementar, producción? ● Tipos de servidores? ● Que tan densos son? ● Qué tipos de discos? ● Qué medio de conección se va a usar? ● Cuántas tarjetas? ● Qué jerarquía se va a configurar? ● Qué protocolos se van a entregar? ● Pool de cache? ● Para qué quieren el cluster!!!!
- 18. No, no se puede tener todo Teorema de CAP
- 19. Problemas comunes. ● Fallas de red no siempre se ven claramente en el cluster. ● Relojes con falta de sincronización ● Falla del device de journal ● Falla de un disco ● % de uso del cluster
- 20. Que leer? ● PAXOS ● Teorema de CAP ● Software Defined Storage ● Papers de Sage Weil en google scholar ● Tesis de doctorado de Sage Weil
- 21. Gracias! Mail -> alsotoes at gmail dot com Twitter -> @alsotoes IRC on chat.freenode.net using nick khyr0n ● #pentoo ● #gentoo ● #gentoo-powerpc ● #ansible ● #openstack ● #openstack-operators ● #openstack-latinamerica IRC on irc.oftc.net using nick khyr0n ● #ceph
Notas del editor
- Scalability Ceph can scale to thousands of nodes and manage storage in the range of petabytes. Speak: nevertheless, Ceph is well known to be a storage system without theoretical boundaries. Commodity hardware No special hardware is required to run a Ceph cluster. Self-managed The Ceph cluster is self-managed: when nodes are added, removed or fail, the cluster automatically redistributes the data. It’s also aware of overloaded disks. No single point of failure for hardware components. No node in a cluster stores information alone. The number of redundant components can be configured. OpenSource software. Ceph is an opensource software solution, independent of specific hardware or vendors. Speak: It's also key to notice lots of companies provides enterprise support, and there are best practices documented using several hardware vendors, but Ceph is not tied to any.
- Data in a ceph cluster is stored in RADOS which stands for RELIABLE AUTONOMIC DISTRIBUTED OBJECT STORE. RADOS is a reliable object storage service that can scale to many thousands of devices it makes uses of the intelligence available in the individual storage nodes. RADOS preserves consistent data across the cluster, while allowing nodes to act semi autonomously for self management, replication, failure detection and failure recovery, it utilices a small cluster map to achieve this.
- Ceph Monitors maintain a “master copy” of the cluster map, which means a Ceph Client can determine the location of all Ceph Monitors, Ceph OSD Daemons, and Ceph Metadata Servers just by connecting to one Ceph Monitor and retrieving a current cluster map. Before Ceph Clients can read from or write to Ceph OSD Daemons or Ceph Metadata Servers, they must connect to a Ceph Monitor first. With a current copy of the cluster map and the CRUSH algorithm, a Ceph Client can compute the location for any object. The ability to compute object locations allows a Ceph Client to talk directly to Ceph OSD Daemons, which is a very important aspect of Ceph’s high scalability and performance. See Scalability and High Availability for additional details. The primary role of the Ceph Monitor is to maintain a master copy of the cluster map. Ceph Monitors also provide authentication and logging services. Ceph Monitors write all changes in the monitor services to a single Paxos instance, and Paxos writes the changes to a key/value store for strong consistency. Ceph Monitors can query the most recent version of the cluster map during sync operations. Ceph Monitors leverage the key/value store’s snapshots and iterators (using leveldb) to perform store-wide synchronization.
- The Ceph Manager daemon (ceph-mgr) runs alongside monitor daemons, to provide additional monitoring and interfaces to external monitoring and management systems. Since the 12.x (luminous) Ceph release, the ceph-mgr daemon is required for normal operations. The ceph-mgr daemon is an optional component in the 11.x (kraken) Ceph release. By default, the manager daemon requires no additional configuration, beyond ensuring it is running. If there is no mgr daemon running, you will see a health warning to that effect, and some of the other information in the output of ceph status will be missing or stale until a mgr is started. Use your normal deployment tools, such as ceph-ansible or ceph-deploy, to set up ceph-mgr daemons on each of your mon nodes. It is not mandatory to place mgr daemons on the same nodes as mons, but it is almost always sensible.