El tema de los monitores es muy amplio, pero el dominador es Nagios.

Un caso de uso es que estamos instalando la plataforma y todavia no tenemos nagios conectado y necesitamos tener ya unos primeros datos en tiempo real. Glances es facil de instalar basado en Python y da mucha información, y de un vistazo como el nombre indica y asi  sin tener que ir lanzando comandos como du ps top. Puede enviar los datos a InfluxDB. InfluxDB es una base de datos de series temporal muy conveniente para explotar logs. Ademas Glances proporciona uns dashboard que se puede importar en Grafana y asi poder monitorizar los datos en remoto y tiempo real. Tambien pudes ejecutarlo en remoto.

La instalación requiere de los "Development Tools", es decir gcc, g++, etc. y por supuesto python. En el caso de CentOS installar Pip. Para ello hay que hacer apuntar el gestor de paquetes yum al repositorio EPEL donde encontraremo
s las librerias de la developemnt tools de python. Se instala con un sudo yum install epel-release, Ahora ya se puede instalar pip.

sudo yum install python-pip python-devel y las development tools

yum group install "Development Tools" y por ultimo pip install glances.

Los componentes a instalar son node.js y Visual Studio Code.  Luego habrá que crear un espacio o workspace y configurar VS.

Instalación Node.js.

No tiene mucho secreto en Windows no debróa de dar problemas, en Linux el npm para evitar hacer sudo cada vez habrá que o cambiarle de usuario con chown o instalarlo en otro sito por ejemplo en el home de cada usuario.

https://docs.npmjs.com/getting-started/fixing-npm-permissions

Creación de una Workarea. 

npm init. Ya esta!!!.  Se creara un ficherito llamado package.json.

Configuración de Visual Studio Code

Con VS se puede editar, depurar sin hacer nada JavaScript, pero si queremos la asitencia de codigo un poco mas avanzada con aistencia de las librerias que se cargan require('libreria') hara falta seguir los pasos explicados en su web.

https://code.visualstudio.com/Docs/languages/javascript

básicamente es crear un fichero jsconfig.json   con el siguiente contenido o el que se quiera.  En micaso ademas le digo que utilizemos la ultima version de JS que ademas. mas verbose

{

    "compilerOptions": {

        "target": "ES6"

    }

}

Y luego hay que instalar el Typing que da la definición de los objetos 

npm install typings --global
typings search node 
typings install dt~node --save --global

en el mismo sitio que esta el jsconfig.json

 

Dos buenos enlaces online para generar, verificar y XSD <--> XML

http://www.freeformatter.com/xsd-generator.html#ad-output

http://xsd2xml.com/

si ademas se quiere pasar a Jason esta es cojonuda la primera me ha fallado.

 http://www.utilities-online.info/xmltojson/#.V9sHTHqbHzg

La verdad es que estan bastante bien y son gratis y no se instalan, te pueden salvar de un apuro rapido si lo que necesitas es cambiar alguna parte de un wsdl o xsd y generar ejemplos para documentar o incluso para tetear

para generar las clases javas es tan facil como ejecutar el xjc. Ojo convertir a Linux formato EOL. Se genera una carpeta /generated con el resultado.

Partiendo de este sencillo XML con solo cpy and paste y con un comando gneramos la clase.


<?xml version="1.0" encoding="utf-8"?>
<product>
  <id>123</id>
  <name>str1234</name>
  <description>str1234</description>
<prices> 
<price>123</price>
<price>121345</price>
</prices>
</product>


MINGW64 /d/software/jdk1.8.0_65/bin
$ ./xjc -xmlschema /d/temp/xsd/test.xsd -verbose


MINGW64 /d/software/jdk1.8.0_65/bin/generated
$ ls
ObjectFactory.java  Product.java




package generated;



import java.util.ArrayList;
import java.util.List;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.XmlType;



@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "", propOrder = {
    "id",
    "name",
    "description",
    "prices"
})
@XmlRootElement(name = "product")
public class Product {

    protected byte id;
    @XmlElement(required = true)
    protected String name;
    @XmlElement(required = true)
    protected String description;
    @XmlElement(required = true)
    protected Product.Prices prices;


    public byte getId() {
        return id;
    }

    public void setId(byte value) {
        this.id = value;
    }

   
     */
    public String getName() {
        return name;
    }

    
     */
    public void setName(String value) {
        this.name = value;
    }

    /**

    public String getDescription() {
        return description;
    }


    public void setDescription(String value) {
        this.description = value;
    }


    public Product.Prices getPrices() {
        return prices;
    }

    
     */
    public void setPrices(Product.Prices value) {
        this.prices = value;
    }



    @XmlAccessorType(XmlAccessType.FIELD)
    @XmlType(name = "", propOrder = {
        "price"
    })
    public static class Prices {

        @XmlElement(type = Integer.class)
        protected List<Integer> price;


        public List<Integer> getPrice() {
            if (price == null) {
                price = new ArrayList<Integer>();
            }
            return this.price;
        }

    }

}




After some experiences with WS saop in my job seem that people are more receptive to use Rest WS. I rather SOAP in legacy system manily because the wsdl is bounded and easy to document . Legacy systems are not flexible so you have to set all the rules beforehand. Legacy systems does not allow agile methods so the scaling out is not a something you have to have in mind. For that reason I think soap WS are more adapeted to PMI projects with traditional stages where the consitence is the key point but not avalaybilty. Nevertheless web and mobile applications are starting to change everything even in legacy systems. The amount of calls and data is doing that avalaiblity is becoming more and more important so caching and scaling out are things to really keep in mind and they are forcing us to set up solutions based in cloud and lightgweight protocols like Rest + JSON. This article is a collection of best practices and things to keep in mind to desing a Rest solution.

USE NOUNS NOT VERBS

I order to avoid a flooding of URI we should use nouns instead of verbs. If we have a entity called product easely your systems is going a need the whole CRUD operations.

\getProducts

\updateProduct 

\addProduct

\findProduct

Therefore you will have at least 4  new uri'. This is a fine graned approach. Another point of view ( Coarse graned) is tak just Product and to take advantage of the http methods to distinghis them.

Technicalle the solition is \products in plural. This is useful in scenarios when you can get object with only a http get call based in Id. Thant is to say GET <uri roo /products/3452352. Of course if you need set more parameters agregated  will be necesry  to do a POST with a json/xm object.

TABLE of HTTP methos

S.N.	HTTP Method, URI and Operation
1	GET http://localhost:8080/UserManagement/rest/UserService/users Get list of users (Read Only)
2	GET http://localhost:8080/UserManagement/rest/UserService/users/1 Get User of Id 1 (Read Only)
3	PUT http://localhost:8080/UserManagement/rest/UserService/users/2 Insert User with Id 2 (Idempotent)
4	POST http://localhost:8080/UserManagement/rest/UserService/users/2 Update User with Id 2 (N/A)
5	DELETE http://localhost:8080/UserManagement/rest/UserService/users/1 Delete User with Id 1 (Idempotent)
6	OPTIONS http://localhost:8080/UserManagement/rest/UserService/users List the supported operations in web service (Read Only)
7	HEAD http://localhost:8080/UserManagement/rest/UserService/users Returns only HTTP Header, no Body. (Read Only)

So you might thinkg there are a biyection correspondece betwen CRUD operations and http methods. HOwever the life is not as easy and

JSON 

Here some  adivices to write json

• Content-type application/json

• Notations follow JS standard or 'CamelCase' so avoid undersocres/hyphen  such as

load_produts. It is better loadProducts

• Dates, numbersStandar described in ISO 8601 so dates numbers and so on has already and standart
• Avoid href in json and set pagination with ofsset and size parameters if there are too many objectos to response. Of courser it only can be achieved if the WS has a sql or database store with a the possibility of opening a cursor.

RESTful security

Stateless is a goal to put your Webservice in MIcroServices or serverless platofrom so try to do sessionless services dooing autentification each reques if it is needed

Never autorizate based on URIs 

Use OAuth1 or 2 or SSL now TSL.

Use API Keys instead of user pwd

For Id's avoid sequential numbers. Good solutions is a UUId's 

Cloud File system.

The industry makes a classification based on the persisting and accesing. Althouthg there are hybrids systems one division you can get across is

Ephemeral Storage. 

This is attached to the cyclelife of the VM. If you VM terminate then your storage will disappear. Nova in Open Satack and Amazon EC2 provide the ephemeral storage automatically. It usually is based on SSD disks.  

Persistence Storage. 

 Persistent storage means that the storage is always avalible no matter the state of the instance or VM. This has also 3 subcategories. Object Storage, Block Storage, Shared File.

We will see some implementations below but a good article is the case of openstack with a good table to make decision. http://docs.openstack.org/ops-guide/arch-storage.html

Table. OpenStack storage

	Ephemeral storage	Block storage	Object storage	Shared File System storage
Used to…	Run operating system and scratch space	Add additional persistent storage to a virtual machine (VM)	Store data, including VM images	Add additional persistent storage to a virtual machine
Accessed through…	A file system	A block device that can be partitioned, formatted, and mounted (such as, /dev/vdc)	The REST API	A Shared File Systems service share (either manila managed or an external one registered in manila) that can be partitioned, formatted and mounted (such as /dev/vdc)
Accessible from…	Within a VM	Within a VM	Anywhere	Within a VM
Managed by…	OpenStack Compute (nova)	OpenStack Block Storage (cinder)	OpenStack Object Storage (swift)	OpenStack Shared File System Storage (manila)
Persists until…	VM is terminated	Deleted by user	Deleted by user	Deleted by user
Sizing determined by…	Administrator configuration of size settings, known as flavors	User specification in initial request	Amount of available physical storage	User specification in initial request Requests for extension Available user-level quotes Limitations applied by Administrator
Encryption set by…	Parameter in nova.conf	Admin establishing encrypted volume type, then user selecting encrypted volume	Not yet available	Shared File Systems service does not apply any additional encryption above what the share’s back-end storage provides
Example of typical usage…	10 GB first disk, 30 GB second disk	1 TB disk	10s of TBs of dataset storage	Depends completely on the size of back-end storage specified when a share was being created. In case of thin provisioning it can be partial space reservation (for more details see Capabilities and Extra-Specs specification)

              

1.       Cephs. State of the art system which has a sort of logic web accessing to Linux .  It gives all the parallelism and redundant data expected in a cloud or distributed systems. Reliability, no single point of failure and scalability. Based on CRUSH. Ceph seems to be more adapted to general purpose than HDFS. As other distributed systems the first step to build a distributed system is decoupled completely the data from its metadata. Ceph has tried to get ride off all clients understanding of the systems and use something similar to bash and libfuse libreries in order to access to files as a POSIX manner.

2.       HDFS. Hadoop distribute file system. As the name shows is the file sysem of the Map Reduce implementation Hadoop. It is used in HBase too. Written in Java, it uses posix on the underlying system and is rack awareness by dns or ip. It is based on Master/Slave arquitecture so it have a Namenode  or master who makes the filesystem operations via RPC interface the slaves are called Datanodes.  

3.       SWIFT. This is an Object Store; it pertains to Open Stack IaaS. Swift provide storage of Blobs via web access. The object store can be used to store data but a typical use case is the storage of images or videos. The link to that objects might be loaded in a traditional data base and the access would be by the web. The API is RESTful services with PUT or GET and the url with the path to the object. The swift is under HA to do this it is balanced using a load balancer + proxies to translate the request to the actual path to the object and its node. The objects are replicated so as to the request can be paralyzed.

4.       CINDER. This is storage falls under the type called block storage. A cinder Volume is attached to the VM directly. You can thing in something like a USB attached to you laptop. However it is needed install the file system because the volume is in raw mode. So it requires as AWS ESB operational expertise.

5.       HIVE. DataBase with MapReduce implementation and gives eventual consistence. It has HQL which is a kind of SQL and translates queries into MapReduce jobs. Hive uses a traditional SQL to store metadata. It can be MySQL, Oracle and other. Note not update or delete soported.

6.       Amazon S3. It provides a service very similar as SWIFT do. So you have a web access through REST, It used to use Soap although now is backing off. S3 also provides a CLI commands in a bash way.  The files can be up to 5 TB. They are stored in a concept called ‘bucket’. Users choose a key to map the object to fetch it. The organization of the bucket is quite flat so there is not organization at all and you can set as many files you want until 5 TB. As Swift it has a week consistency model called eventual consistency. This kind of consistence is the solution to the CAP problem consistency and this tries to give a final consistence consist on if all the writings stopped the system would get the expected value, But concurrent writings does not ensure consistent reads. So you shouldn’t set an ACID system like a bank account database. S3 also provides a CLI commands in a bash way.

7.       Amazon AWS EBS. Elastic Block Storage. It is similar to the Cinder for Open Stack. Amazon provide a list of different types gp2,io1,st1,sc1 based on SSD or Magnetic disks and its IOPs capacity.

8.       Amazon AWS Glacier. Archive service. As its name shows is to long storage to archive files. Archives are stored in ‘vauls’ and if you want download a file from it you are going to need 3 or 5 hours to get ready the files.

9.       Amazon EFS. Elastic File System. It falls under the shared file system category. SSD backed so is fast. Amazon EBS or Cinder requires operation task to prepare the disks and install a file system. EFS provide a fully NFSv4 compliant network access whereas EFS is elastic and grows as needed.  

10.   Drop Box. Based on Amazon S3 and it uses Amazon EC2 for the business logic. It has a two levels of API. Drop-in to embed into Web UI and core API. It has OAuth v1 and v2

VIRTUALIZACION .

Resumen de los tipos de virtualización aprendidos en el curso de Cloud En la virtuzalización la clasificación tiene un compromiso entre aislamiento y seguridad vs rendimiento.

Full virtualización o Emulation.

Este es el mas popular o conocido en el que el gues OS esta totalmente intacto y las llamadas al hardware son virutalizadas o emuladas. Ejemplos son el VirtualBox, Virtual PC, VwWare o QEMU.

Dentro de este grupo o a veces como seperado estan la virtualización mejorada con hardware y la maquina virtual tiene su propio hardware o se permite al Guest Os correr de manera aislada. Intel Vt o AMD-V permiten esta mejora de la virtualización. Ejemplos VMware Fusion, Parallels.

Para-Virtualización.

Se busca sustituir la emulación en la llamadas a perifericos o al hardware las llamadas directas pero 'encapsuladas' para que el hyperevision pueda redireccionarlas. Con ello se obtienen mejores rendimientos entre un 2% - 8% de penalty por el 20% que provoca la full virtualización.

Destaca el ejemplo de Xen. Amazon Cloud usa un hypervisor basado en Xen.

Para lograrlo se modifica el software  Guest para que se pueda comunicar con el hypervison y tambien el softare del kernel del Host llamado dom0 que tiene instalado el hypervisor.

Las llamadas I/O son transferidas desdel el Guest y el hypervision las mapea a llamadas particulares de cada Guest instalado.

Containers o Operating System-Level Virtualization.

Las VS o virtual machies operan sobre un kernel. Puede pasar por ser na mera particion de recursos o un poco mas sofisticado como para dar la sensacion de un servidor real.

Ejemplo es el Linux VServer que permite crear VPS (virtual private servers) que corren simultaneamente en un simple servidor fisico compartiendo recursos. VPS es 'casi' un entorno Linux Server y todos los servicios como ssh, mail y web son iniciados dentro de cada VPS como un servidor real. Cada VPS tiene su propia root y sus propios usuarios y cuentas solo que comparten hardware.

Otros ejemplos de este tipo de virtualizacion es Solaris Zones, VirtualVZ o Linux LXC, esta ultima es la mas senciza y con menos impacto ya que no hay que modificar kernel.

 

 

CLOUDECONOMICS

Siguiendo con el cloud computing.
Hay un estudio de cuando ir al cloud es economico y cuando no . Basicamente hay dos factores a considerar , el tiempo y la distribucion del uso. Joe Wienman es el guru del tema y tiene un libro famoso cloudeconomics que no me he leido pero que es famoso.

Un pequeño analisis ofrecido en cursera es el siguiente

D(t): demand for resources, 0<t<T
P = max( D(t) ): Peak Demand; A = Avg ( D(t) ): Average Demand
B = Baseline (owned) unit cost; BT = Total Baseline Cost
C = Cloud unit cost; CT = Total Cloud Cost
U = C / B : Utility Premium
CT = ∫ U x B x D(t) dt = A x U x B x T
BT = P x B x T debido a que la Baseline debe satisfacer al menos el pico de demanda P.
Cuando un el cloud seria rentable si CT < BT lo cual nos da que sustituyendo por Ct y BT nos da A x U x B x T < P x B x T lo que implica U < P/A .

Consecuencas:
Si la diferencia entre los picos y la media es acusada el cloud externo es una opcion. Por ejemplo sistemas contables con cierres y peridos de auditoria con picos anuales. Otro ejemplo sistemas comerciales donde en epocas de ofertas o campañas promocionales. Si los costes de la infraestructura propia es grande por ejemplo si necesitamos montar una infraestructura sin know how o sin tiempo, tipico en start ups o en medianas empresas.

 

 CHANDY-LAMPORT para la creacion de SNAPSHOTS

Algoritmo para la creacion de snapshoots es decir 'registrar' una foto del estado de cada proceso y cada canl en un entorno sin relog global que es lo normal en sistemas distribuidos.

1. Elecicion del iniciador Pi graba su propio estado.
2. El iniciador genera un mensage especia llamado "Marker" o marcador.
3.  for j=1 to N except i Pi 
1. se envia el mensaje a cada Cij canal (N-1) canalse.
4. Se empieza a grabar por cda uno de los canales de entrada a Pi Cji (j <> i)
5.  Si un proceso Pi recibe un marker por un canal Cki
1. if( es el prmer Marker)
• Pi graba su propio estado y marca Cki como vacio.
2. for j=1 to N exceto i y  K(o sea todos los demas)
• Pi envia un Marker a un canal de salida Cik. 
• Se empieza a grabar por cda uno de los canales de entrada de Pi Cki excepto i,k.
6. else ya se ha recibido un mensaje asi que el se marca el canal Cki y se graban todos los mensages desde que se empezo a grabar Cki y se envian al concetrdor.

Aunque parece lioso basicamente consiste en enviar una señala un canal y el que escucha por ese canal empieza a grabar ese canal. Despues transmte markadores a los otros procesos para que hagan lo mismo. el tema para cuando todos los canales han recibido señal y cada canal se detiene cuando recibe un marcador de ese canal, al final se recogen los mensages intermedios  y se recolectan.

MULTICAST CONCEPTOS

A FIFO ordered. 

Los mensajes enviados por el mismo transmisor son entregados en el orden en que se enviaron. O sea, si un proceso multicast un mensage m antes de otro m' entonces ningn proceso recibe m' a menos que haya recibido previamente m. 

CAUSAL Orden. 

Es una dependencia entre eventos. (Por eventos se entienden envió y recepción de mensajes or ejecución interna en un proceso). Es como una relación de orden.

Se dice que a -> b si.

1º Un proceso ejecuta a primero y luego b.

2º O  si b es el receptor de un mensaje m enviado por a.

3º o si hay un evento h  en medio que actúa transitivamente es decir a-> h y h->b.

Lema

Si hay Causal Orden entonces ha FIFO Orden.

TOTAL Ordering Si dos procesos p y p' reciben ambos mensajes m y m' entonces p recibe m antes de m' si y solo si q recibe m antes que m'. También se le llama Atomic Multicast.

IMPLEMENTACION FIFO

 Sea Pj[i] una matriz  1 <= i <= N.

• Si Pj envia un multicast  actualiza Set Pj[j] = Pj[j] + 1
• Si Pi recibe un mensage de Pj con un numro S enonces
•  if (S == Pi[j] + 1) entrega el mensage.
• else buffer el multicast hasta que la condicion sea cierta.  

O sea que se espera hasta que acabe los previos multicast m y entonces se lee el mensage.

TOTAL ORDERING

Sea Pi  escogido como un proceso 'lider' que mantiene un sequence.
global, cada Pj j<>i mantiene uno loca.
 
El Lider o Sequencer:

• Maitiene a global sequence number S (valor inicial a0)
• Cuando recibe un Mensage M aumenta S++ y hace multicast del par <M,S> a los demas procesos.

El receptor o los otros procesos:

Manitenen una copia del valor recibido. Si Pi recibe un multicas M de Pj espera con buffer hasta que recibe el valor del <M,S(M)> y si Si= 1+S(M) entonces se entrega el mensage y se actualiza Si = Si+1;

Remarks el par <M,S> implica que el mensage M se envia dos veces.