Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via...

34
Cloud Data Management Kapitel 2: Infrastruktur und Services Dr. Anika Groß Wintersemester 2016 Universität Leipzig http://dbs.uni-leipzig.de/

Transcript of Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via...

Page 1: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Cloud Data Management

Kapitel 2: Infrastruktur

und Services

Dr. Anika Groß

Wintersemester 2016

Universität Leipzig

http://dbs.uni-leipzig.de/

Page 2: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Inhaltsverzeichnis

• Hardware-Infrastruktur

– Grundideen performanter Datenverarbeitung in der Cloud

– Aufbau eines Data Centers

• Software-Infrastruktur

– Aufbau, Anforderungen und Ziele

– Cloud-Dienste: Software/Platform/Infrastructure as a Service

• Cloud-Anbieter

– Beispiel: Amazon

• Virtualisierung

Page 3: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

“Big Ideas”

• Scale “out” statt scale “up”

– Grenzen von SMPs (symmetric multi-processors) und großen Shared-Memory-

Maschinen

• Freie Skalierbarkeit

– Flexible Nutzung von Rechner-Ressourcen (“1000 Rechner für 1 Minute”)

• Sequentielle Datenverarbeitung statt wahlfreiem Datenzugriff

– Festplatten: Seeks sind teuer, Datendurchsatz akzeptabel

• Datenverarbeitung dort, wo die Daten liegen (geringe Zugriffszeit)

– Vermeiden unnötigen Datentransfers

Page 4: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Scale-up vs. Scale-out [DGLS99 ff]

• Scale-up = vertikale Skalierung

– schnellere SMP-Knoten

– Shared Everything

• Scale-out = horizontale Skalierung

– N unabhängige Rechner (z.B. Commodity Server)

– Hinzufügen neuer Rechner nach Bedarf

– Shared Nothing oder Shared Disk (Cluster)

• Scale-out in Cloud-Data-Center mit preiswerter Standard-Hardware

– geringere Kosten, geringere Administrationsaufwand, leichte Erweiterbarkeit, ...

– Alternative: geringere Zahl von High-End-Servern

Page 5: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Aufbau eines Datacenters

Server

• CPUs

• DRAM

• Disks

Rack

• 40-80 Server

• Ethernet Switch Cluster

[BH09]

Page 6: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Aufbau eines Datacenters (2)

[BH09]

Bilder von Google‘s Data Center

http://www.google.com/about/datacenters/gallery/#/

Page 7: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Bsp. Google Rechenzentrum

• „Jedes Server-Rack verfügt über vier Switches, die durch verschiedenfarbige Kabel

angeschlossen sind.“

• http://www.google.com/about/datacenters/inside/streetview/

http://www.google.com/about/datacenters/gallery/#/all/10

Page 8: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Bsp. Google Rechenzentrum

• Leitungen zum Transport von Wasser zur Kühlung

http://www.google.com/about/datacenters/gallery/#/all/10

Page 9: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Storage Hierarchy

[BH09]

Page 10: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Standard-Hardware statt “High-End”

• Standard-Hardware ist kosteneffizienter pro “Leistungseinheit”

• Ähnliche Ausfallwahrscheinlichkeiten, geringerer Stromverbrauch

• Nahezu beliebige Skalierbarkeit (“pay as you go/grow”)

[BH09]

Page 11: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

(Ökonomische) Gründe für Data Centers

• Sehr große (50.000 Server) Data Centers kostengünstiger als mittelgroße

(1.000 Server)

– Faktor 5-7 pro Ressource (Netzwerk, Speicher, Administratoren, ...)

• Virtualisierung ermöglicht (nahezu) freie Standortwahl nach

ökonomischen Gesichtspunkten

– Strompreis, Löhne, Steuern, ...

• Große Web-Firmen (Google, Amazon, ...) benötigen große Infrastrukturen

– ... die aber nicht ständig zu 100% ausgelastet sind

– Vermietung von Ressourcen (anfangs) als “Zusatzgeschäft”

http://www.slideshare.net/ISSGC/session-58-cloud-computing-virtualisation-and-the-future-speaker-ake-edlund

Page 12: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Kommunikationskosten

• Parallelverarbeitung erzwingt Kommunikation zwischen Knoten/Cores

– SMP (shared memory): Latenz ~100 ns

– LAN: Latenz ~100 s

• Scaling “up” vs. scaling “out”

– Kleines Cluster of High-End-SMPs vs. großes Cluster of Low-End-SMPs

– Bsp: 8 128-Core-SMP vs. 128 4-Core-SMP

• Einfaches Kostenmodell

– Gesamtkosten: Kosten für Berechnung (1ms) + Kosten für (globalen) Datenzugriff

– Für n Knoten (keine Berücksichtigung der Cores)

• Light communication: f =1

• Medium communication: f =10

• Heavy communication: f =100

1 ms + f [100 ns / n + 100 s (1 - 1/n)]

Page 13: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Kommunikationskosten (2)

• Vergleich: 1 nm-Core vs. n m-Core

• 1 nm-Core bis zu 10mal schneller als entsprechendes n m-Core

Cluster

• keine Veränderung ab n=8

[BH09]

Page 14: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Kommunikationskosten (3)

• Vergleich: (c/128) 128-Core vs. (c/4) 4-Core

– Bsp: Cluster size = 512 entspricht 4 128-Core vs. 128 4-Core

• Sobald “High-End-Server” geclustert werden (müssen), sinkt der

Performanzvorteil deutlich, z.B. <15% ab 1024 cores

• Standard-Hardware-Cluster hat ähnliche Performanz bei deutlich

geringeren Kosten

[BH09]

Page 15: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Seeks vs. Scans

• Sequentielle Verarbeitung großer Datenmengen performant da

aufwändige Seeks entfallen

– Seek = Positionierung des Lese-Schreibkopfes auf Platte

– Computer hard-drive seeking demo: https://youtu.be/jbqPBcMVARE

• Beispiel

– Datenbank mit 1010 Datensätzen à 100 Byte 1 TB

– Update 1% aller Datensätze

• Variante 1: Updates mit Random Access

• Variante 2: Neuschreiben aller Datensätze

Page 16: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Datenzugriff

• Verarbeitung großer Datenmengen u.a. beeinflusst von Zugriffszeiten

• Ziele

– Verarbeitung “nah an” den Daten

– Daten möglichst im RAM

– Sequentielles Lesen von DiskL1 cache reference 0.5 ns

Branch mispredict 5 ns

L2 cache reference 7 ns

Mutex lock/unlock 25 ns

Main memory reference 100 ns

Send 2K bytes over 1 Gbps network 20,000 ns

Read 1 MB sequentially from memory 250,000 ns

Round trip within same datacenter 500,000 ns

Disk seek 10,000,000 ns

Read 1 MB sequentially from disk 20,000,000 ns

Send packet CA → NED → CA 150,000,000 ns

[De09]

Page 17: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Software-Infrastruktur

Facilities

Hardware

Abstraction

Connectivity & Delivery

APIs

Integration & Middleware

DataMeta

DataContent

Applications

APIs

Presentation

Modality/Platform

Infr

astr

uctu

re a

s a

Ser

vice

Pla

tform

as

a S

ervi

ce

Sof

twar

e a

s a

Ser

vice

The frogs who desired a king.

http://www.rationalsurvivability.com/blog/?p=567

IPAM/DNS, Transport, Security, Auth.

VMM, Grid/Cluster, Images

Compute, Network, Storage

Power, HVAC, Space

Structured/Unstructured

Database, Messaging, Queueing

Management

Data/Voice/Video, PC/Embedded/Mobile

Native, Web, Emulated

Page 18: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Cluster-Level Software: Anforderungen

• Ressource Management

– Zuordnung von Tasks zu Ressourcen

– Ziel: Performanz, effizienter Energieverbrauch

• Hardware Abstraction

– Virtualisierung

– Ziel: Einheitlicher (einfacher) Ressourcen-Zugriff

• Deployment und Maintenance

– Software-Upgrades, Monitoring

– Ziel: geringerer Nutzer/Administrator-Aufwand

• Programming Framework

– einfache Realisierung paralleler/web-scale Anwendungen

– Ziel: Erhöhung der Produktivität von Programmierern

Page 19: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Cluster-Level-Software: Besonderheiten

• vs. Desktop-Software

– inhärente Parallelität

• effiziente Ausnutzung aller verfügbarer Ressourcen

– relativ homogene Plattform

• begrenzte Heterogenität durch schrittweise Ersetzen defekter Hardware bzw. Hinzufügen

– große Varianz in Workload

• Varianz der Applikationen, Nutzungsvarianz (Peaks), ...

– “Fault-free“-Anforderung

• Verfügbarkeit trotz täglicher Hardware-Defekte auf Grund Größe eines Data Centers

• vs. High Performance Computing

– nicht vorhersagbarer (Daten-)Input

• Umfang, Schema, ...

– sehr große Datenvolumina

• z.T. auch bei HPC

– nicht nur Computing

• Speicher-Dienste, Datenbanken, Web-Applikationen, ...

Page 20: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Techniken für Performance & Availability

• Replication

– Redundante Speicherung von Daten

– Anwendung: u.a. Dateisystem (GFS/HDFS), Storage Service (Amazon Dynamo)

• Load Balancing

– Workload-Aufteilung auf mehrere Knoten

– Anwendung: parallele Programmierung (MapReduce), WebApps (Google App Engine)

• Data Partitioning

– Aufteilung eines Datenbestandes in mehrere Partitionen zur effizienten Bearbeitung

– Anwendung: u.a. Cloud-Datenbank (Bigtable), parall. Programmierung (MapReduce)

• Eventual Consistency

– Änderungen am Datenbestand werden nicht sofort an Replikate weitergereicht

– Anwendung: Storage Service (Amazon Dynamo)

• Weitere

– Überprüfung ob Nodes “still alive”, Überprüfung der Datenintegrität, Datenkompression

Page 21: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Techniken für Performance & Availability (2)Performance Availability

Replication Effizientes, paralleles Lesen

(Nachteil: Änderungen)

Schutz vor Datenverlust

Data Partitioning Parallele Verarbeitung von Partitionen Recovery schneller bei (kleinen)

Partitionen

Load Balancing Reduzierung der Knoten-Varianz

(langsamster Knoten bestimmt

Gesamtlaufzeit)

---

Eventual

Consistency

Asynchrone Replikation verringert

Antwortzeit bei Writes

Effiziente parallele Writes

Health Checking

und Integritäts-

prüfung

---

Identifikation fehlerhafter

Knoten; keine Requests an nicht

verfügbare/langsame Knoten

Daten-

kompression

Schnellere Datenübertragung/-speicherung

(geringer CPU-Overhead) ---

Page 22: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Infrastructure as a Service

• Bereitstellung (Mieten) von Ressourcen + Infrastruktur-Tools

– CPU, Storage, Network

– “Lokaler Server in der Cloud”

– früher: Utility Computing

• Keine automatische Skalierung

• Hohe Flexibilität

– Bezahlung nach Nutzung (pro CPU-Stunde, pro MB, ...)

– Zeitraum und “Größe” frei wählbar (“1000 CPUs für 1 Stunde”)

• Beispiele

– Amazon Elastic Compute Cloud (EC2), Rackspace

– Amazon Simple Storage Service (S3)

– Amazon Route 53

Page 23: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Platform as a Service

• Framework zur Entwicklung und Bereitstellung von Applikationen

– Infrastruktur führt “hochgeladenen” Quellcode aus

• Begrenzte automatische Skalierung

– Dynamische Allokation von Instanzen je nach Nutzungsaufkommen

– Dynamische Partitionierung von Daten möglich

• Mittlere Flexibilität

– Bezahlung nach Nutzung (CPU, Speicher, Requests, ...)

– Einschränkungen beim Quellcode (Sprache, nutzbare Bibliotheken, ...)

• Beispiele

– Amazon Elastic MapReduce, Hadoop MapReduce

– Google App Engine

Page 24: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Software as a Service

• Bereitstellung von (Web)-Applikationen zur sofortigen Nutzung

– Standardisierte Software (z.B. Office-Produkte, CRM, ...)

– Datenspeicherung i. Allg. beim Anbieter

• Automatische Skalierung durch Anbieter

– definierte Verfügbarkeit / Response-Times möglich

• Flexibilität

– flexible Bezahlung nach Nutzungsumfang (statt Lizenzkosten)

– “Customisierung” nur eingeschränkt möglich

• Beispiele

– Google Apps (Docs, Mail, ...)

– Salesforce

Page 25: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Vergleich IaaS, PaaS und SaaS

IaaS PaaS SaaS

Nutzer Administrator Anwendungsentwickler Endnutzer

Komponenten

Compute Capacity

App Framework +

Compute Capacity

Business Layer +

App Framework +

Compute Capacity

Bezahlung CPU, Speicher, ...

Requests,

Dienstnutzung (DB, Mail, ...) ...

CPU, Speicher, ...

Nutzungsdauer/-

intensität (je nach

App-Typ)

Anwendungs-

fälle

Compute

Capacity

Cloud Storage

Cloud-DB Laufzeit-

umgebung

Erweiterbare

Webapps

WebApps

Beispiele Amazon EC2

+ S3, Azure

Storage

BigTable,

SimpleDB

MapReduce,

Google App

Engine

Facebook Google Mail

Page 26: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Die “Amazon-Cloud”

Building powerful web applications in the AWS Cloud : A Love Story - Jinesh Varia: http://www.slideshare.net/AmazonWebServices/building-powerful-web-applications-in-the-aws-cloud-a-love-story-jinesh-varia

Page 27: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

https://eu-central-1.console.aws.amazon.com/console/home?region=eu-central-1#

Page 28: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

. . .

http://aws.amazon.com/de/free/

Page 29: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Varianten zur Speicherung von Daten

• Weitere Möglichkeiten

– Instance Store/Ephemeral Store: Nicht-persistenter Datei-Speicher für EC2-Instanz

– Relational Database Service: RDBMS via WebService

Content Delivery

(z.B. S3, CloudFront)

Storage

(z.B. Elastic Block Store)

Data Store / Database

(z.B. SimpleDB)

Nutzungs-

szenario

• Große (statische)

Dateien

• Write-Once-Read-Many

• Content Delivery

Network

• Speicherung beliebiger

Daten (ähnlich HDD)

• File-System

• Speicherung (semi-)

strukturierter Daten

• einfache Anfragen

• Hochskalierbare

Anwendungen

Beispiele • Videos, Musik

• Backups

• Speicher für EC2-

Instanz

• Log-Dateien

• Nutzerprofile

Ungeeignet

für / nicht

unterstützt

• Querying

• Searching

• Content Distribution • Komplexe SQL-

Anfragen, z.B. Joins

Best Practices for Architecting in the Cloud - Jeff Barrhttp://www.slideshare.net/AmazonWebServices/best-practices-for-architecting-in-the-cloud-jeff-barr

Page 30: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Amazon EC2

http://aws.amazon.com/ec2

http://www.slideshare.net/guestd0b61e/amazon-ec2-application-design

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instances-and-amis.html

• IaaS: „Mieten von Linux/Win-Instanzen“

– RESTful Webservices (API) zur Allokation und Management

von Ressourcen mittels virtueller Maschinen (VM)

• Amazon Machine Image (AMI)

– Public (vorgefertigt von Amazon) oder

private (von Nutzer erstellt)

– Template mit Software Konfiguration (OS, Anwendungen, ...)

– Starten von Instanzen (Kopien der AMI),

laufen als virtuelle Server in der Cloud

• Beispiel-Auswahl (free)1.) Amazon Linux AMI 2015.03 (HVM), SSD Volume Type

– EBS

– AWS command line tools, Python, Ruby, Perl, Java

– Docker, PHP, MySQL, PostgreSQL, …

2.) Instanz: t2.micro mit vCPU, 1 GB Memory

Page 31: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Instance Types

• Details: http://aws.amazon.com/ec2/instance-types/

• General purpose (t2): high Frequency Intel Xeon Processors operating 2.5GHz

• Preise: Virtual CPU (vCPU) Credits per hour

– Linux oder Windows, Preise (EU Frankfurt),

General purpose (t/m): $0.015 bis $1.15 pro Std

Memory optimized (r): $0.21 bis $4.069 pro Std (15 bis 244 GiB RAM)

(04-2015)

(04-2015)

Page 32: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Amazon EC2: Management

• Bereitstellung aller Funktionen per SOAP/REST-API

– Programmatischen Zugriff + Web Interface für manuellen Zugriff

• Workflow

– Ggf. AMI-Upload; Speicherung durch Elastic Block Storage

– Reservierung physikalischer Ressourcen, Kopieren auf (phys.) Server

– Starten der VM = Instanziierung des AMI

– Zugriff mittels IP und SSH (Linux) bzw. RDP (Windows)

– Ggf. Einbinden weiterer Dienste

Page 33: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

Amazon EC2: Abrechnung

• Bsp. Massive Nutzung für Forschungsprojekt (vgl: 1 Jahr = 8760 Stunden)

Page 34: Cloud Data Management - Abteilung Datenbanken Leipzig · – Relational Database Service: RDBMS via WebService Content Delivery (z.B. S3, CloudFront) Storage (z.B. Elastic Block Store)

EC2-Integration mit anderen Diensten

• Elastic Block Store (EBS)

– Persistenter Blockspeicher, der zur Laufzeit mit EC2-VM verbunden werden kann

– Nutzung: Dateispeicher (Formatierung mit FS), Snapshot für VM, …

– Preis (04/15): $0.119 pro GB und Monat von bereitgestelltem Speicher (SSD);

$0,11 pro 1 Million I/O Requests

• Elastic IP

– EC2-VMs erhalten zufällige IP aus EC2-IP-Pool

– Unvorteilhaft für einfachen Nutzer-Zugriff (z.B. Webserver)

– Zuordnung statischer IP(s) zu EC2-VM

– Preis (04/15): ab $0.00 ($0.005) für (nicht) laufende EC2-VM pro Stunde

• Elastic Load Balancing (ELB)

– Automatische Verteilung eingehender Requests auf EC2-Instanzen

– Requests von einem Nutzer stets zur selben Instanz

– Erkennung ausgefallener VMs

– Preis (04/15): $0.03 pro Stunde (EU Frankfurt) + $0.008 pro GB Datentransfer