Post on 29-Nov-2015
transcript
TRABAJO MONOGRAFICO
ASIGNATURA: REDES Y BASE DE DATOS
TEMA: “DIRECCIONAMIENTO IPV6”
“BASE DE DATOS”
PRESENTADO POR:
ALUMNO: GUTIERREZ SOTO, LUIS EDUARDO
LIMA – PERÚ
2013
INDICE GENERALCAPITULO 1. DIRECCION IPV6............................................................................................4
1.1. DEFINICION...............................................................................................................4
1.2. TIPOS..........................................................................................................................4
1.3. FORMATOS DE DIRECCION.................................................................................5
a. Formato de dirección Unicast y Anycast...........................................................5
b. Formato de dirección de enlace-local................................................................6
c. Formato de dirección multicast Solicited-node...............................................6
d...........................................................................................................................................6
d. Formato de dirección Multicast...........................................................................6
e. Flags de la dirección Multicast............................................................................6
f. Formato de dirección multicast Prefijo-Unicast (unicast-prefix-based)....7
1.4. REPRESENTACION.................................................................................................7
1.5. REDES........................................................................................................................8
1.6. AMBITO DE DIRECCION IPV6...............................................................................9
1.7. ESPACIO DE DIRECCIONAMIENTO IPV6........................................................10
a. Asignación general..................................................................................................10
b. Direcciones anycast reservadas............................................................................11
1.8. SELECCIÓN AUTOMATICA DE DIRECCION...................................................12
1.9. TRANSICION...........................................................................................................13
CAPITULO 2. SERVIDORES DE BASE DE DATOS........................................................14
a. Servidores de bases de dato relacionales..........................................................15
2.1. LA SEGURIDAD......................................................................................................17
2.2. EL SOPORTE DE RED..........................................................................................18
2.3. INTERNET Y BASES DE DATOS DISTRIBUIDAS...........................................19
2.4. HERRAMIENTAS DE ADMINISTRACIÓN..........................................................21
2.5. PLATAFORMAS Y PROGRAMACIÓN...............................................................24
2.6. EL SOPORTE HARDWARE NECESARIO.........................................................25
3. CONCLUSIONES............................................................................................................26
a. Ipv6................................................................................................................................26
b. Base de Datos............................................................................................................26
4. RECOMENDACIONES...................................................................................................26
a. Ipv6................................................................................................................................26
b. Base de Datos............................................................................................................27
5. BIBLIOGRAFIA...............................................................................................................27
a. Ipv6................................................................................................................................27
b. Base de Datos............................................................................................................27
CAPITULO 1. DIRECCION IPV6
1.1. DEFINICION
Una Dirección de Internet Protocol Versión 6 (Dirección IPv6) es
una etiqueta numérica usada para identificar un interfaz de
red (elemento de comunicación/conexión) de un ordenador o nodo de
red participando en una red IPv6.
Las direcciones IP se usan para identificar de manera única una
interfaz de red de un Host, localizarlo en la red y de ese modo
encaminar paquetes IP entre hosts. Con este objetivo, las direcciones
IP aparecen en campos de la cabecera IP indicando el origen y destino
del paquete.
IPv6 es el sucesor del primer protocolo de direccionamiento
de Internet, Internet Protocol versión 4 (IPv4). A diferencia de IPv4, que
utiliza una dirección IP de 32 bits, las direcciones IPv6 tienen un
tamaño de 128 bits. Por lo tanto, IPv6 tiene un espacio de direcciones
mucho más amplio que IPv4.
1.2. TIPOS
Las direcciones IPv6 se clasifican según las políticas de
direccionamiento y encaminamiento más comunes en redes:
direcciones unicast, anycast y multicast.1
Una dirección unicast identifica un único interface de red. El
protocolo de Internet entrega los paquetes enviados a una
dirección unicast al interface específico.
Una dirección anycast es asignada a un grupo de interfaces,
normalmente de nodos diferentes. Un paquete enviado a una
dirección anycast se entrega únicamente a uno de los miembros,
típicamente el host con menos coste, según la definición de
métrica del protocolo de encaminamiento. Las direcciones anycast
no se identifican fácilmente pues tienen el mismo formato que las
unicast, diferenciándose únicamente por estar presente en varios
puntos de la red. Casi cualquier dirección unicast puede utilizarse
como dirección anycast.
Una dirección multicast también es usada por múltiples hosts, que
consiguen la dirección multicast participando en el protocolo de
multidifusión (multicast) entre los routers de red. Un paquete
enviado a una dirección multicast es entregado a todos los
interfaces que se hayan unido al grupo multicast correspondiente.
IPv6 no implementa direcciones broadcast. El mismo efecto puede
lograrse enviando un paquete al grupo de multicast de enlace-local
todos los nodos (all-nodes) ff02::1. Sin embargo, no se recomienda el
uso del grupo all-nodes, y la mayoría de protocolos IPv6 usan un grupo
multicast de enlace-local exclusivo en lugar de molestar a todos los
interfaces de la red.
1.3. FORMATOS DE DIRECCION
Una dirección IPv6 está formada por 128 bits.1 Las direcciones se
clasifican en diferentes tipos: unicast, multicast y anycast. Cada uno de
los tipos define valores específicos para subgrupos de los 128 bits,
asociando dicho valor con las características especiales del tipo.
a. Formato de dirección Unicast y Anycast
Las direcciones Unicast y anycast generalmente se dividen en dos
grupos lógicos: los primeros 64bits identifican el prefijo de red, y
son usados para encaminamiento; los últimos 64bits identifican el
interface de red del host.
Ejemplo de formato de dirección unicast (el tamaño del routing-prefix es
variable)
bits 48 (o más) 16 (o menos) 64
campo routing prefix subnet id interface identifier
El prefijo de red (network prefix) (prefijo de encaminamiento
o (routing prefix) junto con el identificador de subred o (subnet id))
está situado en los 64 bits más significativos de la dirección ipv6. El
tamaño del routing prefix puede variar; un prefijo de mayor tamaño
significa un tamaño menor para subnet id. El subnet id permite a
los administradores de red definir subredes dentro de la red
disponible.
Los 64 bits de identificador del interface (interface identifier) son
generados automáticamente con la dirección MAC del interface y el
algoritmo EUI-64 modificado, obtenidos de un servidorDHCPv6,
establecidos aleatoriamente o asignados manualmente.
Una dirección de enlace-local es una dirección unicast, pero
usando un valor específico para el network prefix.
b. Formato de dirección de enlace-local
El campo prefijo contiene el valor binario 1111111010 (fe80::/10).
Los 54 ceros siguientes consiguen que el prefijo de red sea el
mismo para todas las direcciones locales, y por tanto no enrutable.
c. Formato de dirección multicast Solicited-node
d.
d. Formato de dirección Multicast
Las direcciones Multicast se construyen en función de
determinadas reglas, dependiendo de la aplicación.
bits 8 4 4 112
campo prefix flagsscop
egroup ID
valor1111111
10RPT XXXX
El campo prefix mantiene el valor binario 11111111 para cualquier
dirección multicast.
Actualmente se utilizan 3 de los 4 bits del campo flags (flags);1 el bit
de flag más significativo está reservado para uso futuro.
e. Flags de la dirección Multicast
bits 10 54 64
campo prefijo ceros interface identifier
bits 8 4 4 79 9 24
camp
oprefix flags scope ceros unos dirección unicast
valor 11111111 0000 0010 00000000...00000000 111111111
Flag 0 1
R
(Rendezvous)
Rendezvous point not embedded
(traducción necesaria)
Rendezvous point embedded
(traducción necesaria)
P (Prefijo) Sin información de prefijo Dirección basada en prefijo de red
T (Transitoria)Dirección multicast mundialmente
válida (permanente)
Dirección multicast asignada
dinámicamente (temporal)
Los 4-bits del campo scope (ámbito) se utilizan para indicar dónde
la dirección es válida y única.
Hay direcciones multicast especiales, como la Solicited-node:
Los campos prefix y scope tienen los valores
binarios 11111111 y 0010. Las direcciones multicast Solicited-
node son construidas a partir de la dirección unicast o anycast,
copiando los últimos 24 bits de la dirección unicast o anycast en los
últimos 24 bits de la dirección multicast.
f. Formato de dirección multicast Prefijo-Unicast (unicast-prefix-
based)
bits 8 4 4 4 4 8 64 32
camp
oprefix
flg
ssc res
rii
dplen prefijo de red group ID
Las direcciones multicast de multidifusión (link-scoped) usan un
formato parecido.
1.4. REPRESENTACION
Una dirección IPv6 (128 bits) se representa mediante ocho grupos de
cuatro dígitos hexadecimales, cada grupo representando
16 bits (dos octetos). Los grupos se separan mediante dos puntos(:).
Un ejemplo de dirección IPv6 podría ser:
2001:0db8:85a3:0000:0000:8a2e:0370:7334
Los dígitos hexadecimales no son sensibles a mayúsculas/minúsculas,
pero se aconseja la utilización de minúsculas.9
Esta representación completa puede ser simplificada de varias
maneras, eliminando partes de la representación.
a. Ceros iniciales
Los ceros iniciales de cada grupo pueden omitirse, aunque cada
grupo debe contener al menos un dígito hexadecimal.1 De ese
modo, la dirección IPv6 ejemplo podría escribirse:
2001:db8:85a3:0:0:8a2e:370:7334
b. Grupos de ceros
Uno o más grupos de ceros pueden ser sustituidos por dos
puntos.1 Esta sustitución puede realizarse únicamente una vez en
la dirección. En caso contrario, obtendríamos una representación
ambigua. Si pueden hacerse varias sustituciones, debemos hacer
la de mayor número de grupos; si el número de grupos es igual,
debemos hacer la situada más a la izquierda.9 Con esta regla,
reduciríamos aún más la dirección ejemplo:
2001:db8:85a3:8a2e:370:7334
La dirección de loopback, 0:0:0:0:0:0:0:1, y la dirección IPv6
indefinida, 0:0:0:0:0:0:0:0, se reducen a ::1 y :: respectivamente.
c. Notación decimal con puntos
Durante la transición de Internet de IPv4 a IPv6 será típico operar
en entornos de doble direccionamiento (IPv4 e IPv6). Por este
motivo se ha introducido una notación especial para expresar
direcciones IPv6 que sean IPv4-mapeada o IPv4-compatible,
representando los últimos 32 bits de la dirección IPv6 en el formato
decimal con puntos usado en IPv4.
Por ejemplo, la dirección IPv6 del tipo IPv4-
mapeada ::ffff:c000:280 se puede representar
como ::ffff:192.0.2.128, mostrando claramente la dirección IPv4
mapeada dentro de la IPv6.
1.5. REDES
Una red IPv6 utiliza un grupo de direcciones IPv6 contiguas, de un
tamaño potencia de dos. La parte inicial de las direcciones son
idénticas para todos los hosts de una red, y se llama dirección de red o
prefijo de encaminamiento (routing prefix). Las direcciones de red se
escriben en notación CIDR una red se representa por la primera
dirección del grupo (que debe terminar en ceros), una barra
invertida (/), y el número de bits del prefijo en decimal. Por ejemplo, la
red 2001:db8:1234::/48 comienza en la
dirección 2001:0db8:1234:0000:0000:0000:0000:0000 y finaliza
en 2001:0db8:1234:ffff:ffff:ffff:ffff:ffff.
Veámoslo con mayor detalle:
1.6. AMBITO DE DIRECCION IPV6
Toda dirección IPv6, excepto la dirección indefinida (::), tiene un
"ámbito" (scope en inglés),11 que determina en qué partes de la red es
válida.
En direccionamiento unicast, las direcciones de enlace-local y
la dirección de loopback tienen ámbito de enlace local, es decir, deben
ser usadas en la red directamente conectada. El resto de direcciones,
excepto aquellas privadas, tienen ámbito global (o universal), que
significa que son mundialmente enrutables y pueden ser usadas para
conectarse a direcciones de ámbito global en cualquier lugar, o a
direcciones de ámbito enlace-local en la red directamente conectada.
El ámbito de una dirección anycast se define del mismo modo que en
las direcciones unicast.
Para multicast, los cuatros bits menos significativos del segundo octeto
de una dirección multicast (ff0X::) identifican el ámbito, es decir, hasta
dónde se propaga el tráfico multicast. Los ámbitos1 definidos
actualmente son:
Ámbito dirección IPv6 Multicast
Valor Ámbito Descripción
(scope)
0x0 reserved
0x1 interface-localEl ámbito interface-local abarca sólo un único interfaz de un nodo,
y es útil sólo para la transmisión loopback del tráfico multicast.
0x2 link-localLos ámbitos de enlace-local y site-local abarcan las mismas
regiones que los ámbitos unicast correspondientes.
0x4 admin-local
El ámbito admin-local es el más pequeño que debe ser
configurado manualmente, es decir, no deriva automáticamente de
la conexión física sin relación alguna con multicast.
0x5 site-localLos ámbitos de enlace-local y site-local abarcan las mismas
regiones que los ámbitos unicast correspondientes.
0x8organization-
local
El ámbito de organization-local abarca multiples ubicaciones que
pertenecen a la misma organización.
0xe global
0xf reserved
1.7. ESPACIO DE DIRECCIONAMIENTO IPV6
a. Asignación general
El Internet Architecture Board (Comité de Arquitectura de
Internet) y el Internet Engineering Steering Group (Dirección de
Ingeniería de Internet) delegaron la asignación del
direccionamiento IPv6 en la Internet Assigned Numbers
Authority (IANA).12 Su función principal es la asignación de
grandes bloques de direcciones a los Registros Regionales de
Internet (RIRs por sus siglas en inglés), que tienen la tarea de
asignar trozos menores a Proveedores de Internet u otros registros
locales. IANA ha mantenido la lista oficial de las asignaciones del
espacio de direcciones IPv6 desde diciembre de 1995.13
Actualmente, sólo la octava parte del espacio total de direcciones
están disponibles para su uso en Internet. La mayor parte de las
direcciones IPv6 están reservadas para uso futuro. Para conseguir
agregación de rutas, reduciendo así el tamaño de las tablas de
rutas de Internet, el rango 2000::/3 se asigna a los RIRs en grandes
bloques desde /23 hasta /12.14
Los RIRs asignan rangos menores a ISPs, que luego distribuyen en
bloques de /48 a sus clientes. Los registros de asignaciones
globales pueden encontrarse en los RIRs u otros webs.15
Las direcciones IPv6 se asignan a las organizaciones en bloques
mucho mayores a las asignaciones IPv4; la asignación
recomendada es un rango /48, que es 248 ó 2.8×1014 veces mayor
que el direccionamiento IPv4 completo. A pesar de ello, el conjunto
total es suficiente para el futuro previsible, pues hay 2128 ó sobre
3.4×1038 direcciones IPv6.
Cada RIR puede dividir cada uno de sus bloques /23 en 512
bloques /32, normalmente uno para cada ISP. Un ISP puede dividir
cada uno de sus rangos /32 en 65.536 bloques /48, normalmente
uno para cada cliente.16 Los clientes pueden crear 65.536
redes /64 con su asignación /48, teniendo cada red un número de
direcciones que es el cuadrado de todo el espacio de direcciones
IPv4, que sólo tenía 232 ó 4.3×109 direcciones.
Tal y como se ha diseñado, sólo una pequeña fracción del espacio
de direcciones se utilizarán realmente. El amplio espacio de
direcciones asegura que prácticamente siempre habrá
disponibilidad, lo que convertirá a la traducción de
direcciones (NAT) en innecesaria desde un punto de vista de
direccionamiento. NAT se utiliza actualmente sobre todo para
aliviar elagotamiento de las direcciones IPv4, pero también tiene
aspecto económico ya que el alquiler de direcciones IP tiene un
coste. Desde un punto de vista de la seguridad evita exponer
información de estructura y gestión interna de red hacia internet.
b. Direcciones anycast reservadas
La dirección más baja de cada subred (identificador de interface
todo a ceros) está reservada como dirección anycast subnet-
router (subred de router).1 Las aplicaciones pueden utilizar esta
dirección destino para hablar con algún router de la subred,
garantizando IPv6 que estos paquetes son entregados únicamente
a un router de la subred.
Las 128 direcciones más altas de cada subred /64 están
reservadas como direcciones anycast.17 Estas direcciones suelen
tener los 57 primeros bits del identificador de interface a 1,
seguidos de 7 bits de identificador anycast. Los prefijos de red,
incluidos subredes, requieren tener 64 bits de longitud, en cuyo
caso el bit universal/local debe ser puesto a 0 para indicar que la
dirección no es globalmente única. Si la dirección tiene el
valor 0x7e en los 7 bits menos significativos, se define como una
dirección anycast de home agent (agente inicial) en IP Móvil. La
dirección con los 7 bits menos significativos a 1 (valor 0x7f) está
reservada y no puede ser usada. No hay más asignaciones, por lo
que los valores desde 0x00 hasta 0x7d están reservados también.
1.8. SELECCIÓN AUTOMATICA DE DIRECCION
Los interfaces de red habilitados para IPv6 tienen normalmente más de
una dirección IPv6, por ejemplo una dirección de enlace-local y una
dirección global, o direcciones permanentes versus temporales. IPv6
introduce los conceptos de alcance y preferencia, dando múltiples
opciones para seleccionar la dirección origen y destino en
comunicaciones con otros hosts.
El algoritmo de selección de preferencia,33 que elige la dirección más
apropiada para usar en la comunicación con un destino concreto
(incluyendo el uso de direcciones IPv4-mapeadas en implementaciones
de doble pila) está basado en una tabla de preferencias configuradas
por el usuario, que asocia cada prefijo de red con un nivel de prioridad.
La tabla por defecto sería como la siguiente:
Tabla de Políticas de Prefijos
Prefijo Prioridad Etiqueta
::1/128
::/0
2002::/16
::/96
50
40
30
20
0
1
2
3
::ffff:0:0/96 10 4
En una configuración por defecto, IPv6 tendrá mayor prioridad que
IPv4, y también utilizará direcciones destino con el ámbito más
pequeño posible, de modo que las comunicaciones de enlace-local son
preferidas a caminos globales cuando ambos sean igualmente
adecuados. La tabla de políticas de prefijos es similar a una tabla de
rutas, con el valor de prioridad haciendo de coste de enlace y donde
mayor preferencia es expresada como un valor mayor. Las direcciones
origen candidatas se obtienen del Sistema Operativo, y las direcciones
destino candidatas pueden ser consultadas vía Domain Name
System (DNS). Después se cruzan con la tabla de políticas de prefijos,
seleccionando el prefijo de mayor número de bits de entre las entradas
donde la dirección IPv6 hace match.
1.9. TRANSICION
Desde 2009, muchos dispositivos NAT y routers en los hogares todavía
gestionan incorrectamente los registros AAAA.35 Algunos de ellos
simplemente desechan las peticiones DNS a estos registros, en lugar
de devolver una respuesta negativa apropiada. Debido a que la petición
es desechada, el host debe esperar el timeout de esa petición. Esto, a
menudo, causa una percepción de lentitud en la conexión de hosts
IPv6.
CAPITULO 2. SERVIDORES DE BASE DE DATOS
Grandes proveedores de información para todo tipo de usuarios.
Los servidores de bases de datos surgen con motivo de la necesidad de las
empresas de manejar grandes y complejos volúmenes de datos, al tiempo
que requieren compartir la información con un conjunto de clientes (que
pueden ser tanto aplicaciones como usuarios) de una manera segura. Ante
este enfoque, un sistema gestor de bases de datos (SGBD, a partir de
ahora) deberá ofrecer soluciones de forma fiable, rentable y de alto
rendimiento. A estas tres características, le debemos añadir una más: debe
proporcionar servicios de forma global y, en la medida de lo posible,
independientemente de la plataforma. Internet se ha convertido en nuestros
días en la mayor plataforma de comunicaciones jamás vista. Esto hace que
las empresas tiendan a presentar su información a través de la Web en
forma de contenidos, que después los clientes consultarán para establecer
relaciones con dichas empresas.
Una de las funciones que se empieza a exigir a los SGBD, puesto que
sobre ellos recae el peso del almacén y proceso de la información, es la de
proporcionar herramientas de apoyo a toma de decisiones
("datawarehouse") al tiempo que proporciona una plataforma de
transacciones "on-line" (OLTP) que hacen que la información esté siempre
actualizada y consistente. A lo largo del artículo iremos comentando las
prestaciones de ambas implementaciones y cómo influye el SGBD en el
proceso de las mismas.
Aunque parece clara la función de un SGBD, en la actualidad cada vez
más filosofías y tecnologías tienden a confluir en un mismo punto. Ya se
está hablando acerca de las posibilidades de los nuevos SGBD de poder
almacenar contenidos multimedia, objetos, documentos complejos... La
explosión de nuevos servicios ha hecho que cada vez más aplicaciones
dependan de estos servidores de datos, delegando la responsabilidad de la
gestión y almacenamiento de la información a aquellos que mejor están
preparados para su tratamiento.
Para poder lograr estos objetivos, es un punto muy importante el que los
SGBD proporcionen herramientas de administración completas (que
simplifiquen la tarea de la configuración, seguridad, creación y gestión de
bases de datos al tiempo que proporcionan mecanismos de integración con
otros sistemas y políticas de copias de seguridad) y herramientas que
permitan su programación (tanto a nivel de diseño como a nivel de reglas y
procedimientos que encapsulen la arquitectura de la base de datos, de tal
manera que, a través de conectores a datos, las aplicaciones sólo tengan
que pedir la información que necesitan sin preocuparse de cómo se
encuentra almacenada).
Por último, puesto que los datos deben estar por encima de la plataforma,
los SGBD deben proporcionar mecanismos de comunicación con otras
plataformas que actúen también como clientes o servidores de datos. Lo
que nos lleva al último punto que consideraremos: la posibilidad de la
replicación de la información, posibilidad que permitirá que la información
pueda estar almacenada en múltiples servidores de datos y accesible
desde cualquier punto como si se tratase de un único volumen de
información.
a. Servidores de bases de dato relacionales
Antes de comenzar a comentar las características a analizar de los
SGBD, el primer paso es el de definir qué es un servidor de bases de
datos relacionales y sus cometidos principales. Un servidor de bases
de datos relacionales es un sistema bajo arquitectura cliente/servidor
que proporciona servicios de gestión, administración y protección de la
información (datos) a través de conexiones de red, gobernadas por
unos protocolos definidos y a los que acceden los usuarios, de modo
concurrente, a través de aplicaciones clientes (bien sean herramientas
del propio sistema como aplicaciones de terceros).
Dichos servidores solucionan los problemas de las empresas al
manejar grandes volúmenes de información de una manera estable,
fiable, coherente y segura en un entorno heterogéneo de trabajo y de
necesidades de información.
La información se almacenará de modo lógico de una manera
relacional, como ya se ha visto, en la que un conjunto de
almacenamientos que llamaremos tablas (y que se componen de un
conjunto de campos que describen su contenido, y a los cuales
denominaremos columnas) se relacionan entre sí a través de un
conjunto definido de claves. Una de las responsabilidades del sistema y
del diseño de la base de datos, será el que sea posible mostrar aquella
información requerida a través de conjuntos de datos planos (que
llamaremos cursores), independizando las relaciones establecidas y la
arquitectura de la base de datos de la necesidad de información del
usuario. Para proteger la información el sistema contará con
mecanismos de control de transacciones basados en reglas que
denominaremos disparadores, reglas de definición del tipo de entrada
de datos y reglas de validación de las entradas de datos. Mediante
complejos sistemas de indexación, estos sistemas serán capaces de
ordenar y acelerar las consultas a la información requerida. Cuanto
mejor se indexen los datos, más rápidas se realizarán las consultas.
Por último, y como un factor muy importante de cara al diseño de bases
de datos, los sistemas deben proporcionar la posibilidad de automatizar
operaciones de acceso, filtrado y control de los datos, a través de los
procedimientos almacenados.
Todo ello se podrá realizar a través del lenguaje SQL (Structured Query
Language, lenguaje estructurado de consulta) que se ha convertido en
el estándar de interfaz de estos sistemas para su diseño, desarrollo y
consultas de informaci6n. Desarrollado por IBM, se ha convertido en un
estándar para el manejo de estos sistemas y queda recogido en la
norma ANSI SQL'92, en la cual quedan registradas aquellas sentencias
SQL que deben estar presentes en todo sistema gestor de bases de
datos. En este apartado, que es donde los SGBD demuestran sus
propios dones, es donde ya nos separamos del estándar, pues cada
fabricante añadirá sus propias extensiones al lenguaje para
aprovechar, como es lógico, las ventajas de sus propios motores.
De lo indicado en los párrafos anteriores podremos obtener algunos de
los parámetros que emplearemos en la comparativa: capacidad del
servidor de conexión con el exterior; capacidad de atender peticiones
concurrentes de clientes; seguridad del sistema; herramientas de
administraci6n disponibles; herramientas de administración y
automatización de tareas que reduzcan el TCO ("Total Cost Owner") y,
por último, la cantidad de plataformas en la que se puede integrar el
sistema.
2.1. LA SEGURIDAD
En todo sistema abierto, debe proporcionarse un potente mecanismo
de seguridad que garantice que ningún intruso pueda acceder o
corromper la integridad del sistema. Si este concepto ya es crítico en
los sistemas operativos actuales, hay que imaginarse cuánto más es
de importante este concepto cuando ya no hablamos de recursos del
sistema (como puedan ser archivos o correos, más o menos
importantes) sino de información crítica para la empresa, en la que se
almacenan datos de contabilidad, gestión, personal, o estratégicos de
la cual depende para su existencia.
En servidores de bases de datos hablaremos de la seguridad a 4
niveles básicos: seguridad de acceso al sistema, seguridad a nivel de
objetos de datos, seguridad a nivel de datos y seguridad en cuanto a
protección de los almacenamientos físicos de los datos.
La seguridad de acceso se implementará de dos maneras posibles: a
nivel de sistema operativo, en cuyo caso el SGBD se apoya en la
seguridad de entrada al sistema operativo para comprobar la validez
del acceso a los datos almacenados; o bien lo que llamaremos modo
mixto, en el cual la seguridad de entrada a la información la llevará a
cabo el propio servidor de datos a partir de la definición de cuentas de
usuario al servidor (su denominación de mixta proviene de la
capacidad de los sistemas de incluir como cuentas de acceso o login
aquellas propias del sistema operativo, lo que facilita la transición de
las cuentas de seguridad). La segunda será de gran ayuda cuando los
clientes que acceden al sistema provienen de sistemas operativos con
poca (o ninguna) seguridad o de aplicaciones instaladas que
necesiten acceder a los volúmenes de información del sistema. En
ambos casos, en los sistemas se contará con roles o papeles con los
que contará el usuario al entrar al sistema para la realización de
determinadas operaciones de cara al sistema.
La seguridad a nivel de objetos entra ya en el detalle del acceso a
nivel de creación y administración de objetos de datos: tablas, vistas,
índices, relaciones, reglas...etc. Es decir, las responsabilidades y
acciones que puede hacer el usuario en el esquema de la base de
datos (el esqueleto a partir del cual el sistema definirá cómo se debe
almacenar y relacionar la información). Se podrán especificar de
nuevo roles a los usuarios, indicando quién podrá crear, modificar o
eliminar cualquier objeto de datos (con lo que se permite establecer
una política de delegación de responsabilidades).
La seguridad a nivel de datos entra ya en la capa de la información en
sí. En la que indicaremos quién puede acceder a qué información
para su consulta, actualización, inserción o borrado. Las
características de los diversos motores determinarán hasta qué grado
de seguridad se llega en este apartado (desde la protección de las
columnas de una tabla hasta la tabla en sí, creación de vistas...etc.).
Por último, la seguridad a nivel de protección de los almacenamientos
físicos de la información. Tendremos dos aproximaciones: la
seguridad a nivel de sistema operativo de los archivos de datos del
sistema, y las políticas de copia de seguridad y restauración de los
datos (tanto con herramientas del sistema operativo como las
proporcionadas por el propio servidor de datos) junto con sus posibles
aproximaciones (total, incremental y diferencial), además de los
soportes hardware compatibles de almacenamiento masivo
empleados como destino de las copias.
2.2. EL SOPORTE DE RED
Puesto que se está implementando una solución cliente/servidor, es
un elemento fundamental para la conexión entre los distintos clientes
y el servidor un canal apropiado para la comunicación, que posibilite
el intercambio de información. Los servidores de datos deben
proporcionar mecanismos de comunicación óptimos, pues de cómo se
envíe la información dependerán parámetros tan importantes como la
velocidad de acceso a los datos. Todos los sistemas gestores
analizados cuentan con múltiples configuraciones de protocolos,
adaptándose a los protocolos existentes y estandarizados de la
actualidad: TCP/IP, IPX, Banyan..., aunque el que tiene un auge
imparable en este tipo de servicios es el omnipresente TCP/IP, lo que
garantiza que la conexi6n de nuestros servidores estará al alcance de
cualquier usuario desde cualquier parte del mundo.
Es importante no sólo el canal de comunicaciones que está disponible
para los servidores de datos sino también cómo es transmitida la
información. Es lógico pensar que tienen que existir posibilidades de
encriptación de la información para prevenir accesos no autorizados
así como mecanismos de partición de los datos, para evitar que
peticiones masivas de información sobrecarguen el ancho de banda
de la red. Además, será una cuestión de optimización el saber que no
toda la información es necesaria al mismo tiempo, y que el servidor
debe ser capaz de ir proveyendo la información requerida en el
momento justo en el que es necesaria (lo que ahorra ancho de banda
y recursos de la máquina).
La configuración de las librerías de red dependerá mucho del tipo de
sistema operativo que se encuentre en explotación. Y será un
componente a configurar tanto en la máquina servidor como en los
puestos cliente.
Este apartado también dependerá del tipo de plataforma empleada.
Recalcar que el proceso de configuración de los clientes deberá ser
un proceso sencillo, que en la mayoría de los casos sólo implica
conocer el nombre del servidor de datos y las cuentas oportunas,
siendo el propio sistema operativo el encargado de encontrar los
servidores referenciados (bien a través de un nombre DNS, una
dirección IP o un nombre de servicio con un Puerto de escucha).
2.3. INTERNET Y BASES DE DATOS DISTRIBUIDAS
Puesto que todo tiende a unificarse con Internet, los servidores de
datos también deben proporcionar servicios de datos a la Red. Los
servicios disponibles incorporan generación y alimentación de páginas
Web a partir de consultas prediseñadas en la base de datos.
Dichas consultas mantendrán alimentadas las páginas Web, las
cuales estarán siempre actualizadas con la última información.
Cuanto mayor sea el grado de integración con la Web, mejor podrá
ser la presentación de información crítica de la empresa en las
páginas. Los servidores de datos deben proporcionar mecanismos de
actualización automática de las páginas, de manera que se asegure
que cualquier cambio efectuado en la base de datos se haga efectivo
en la correspondiente página Web. De esta manera, la integridad de
la informaci6n también estará implementada a nivel de servicios de la
Red. Lógicamente, también hay que pensar que esto no es viable de
cara a actualizaciones masivas de datos, lo que implica una
sobrecarga del servidor (pues no sólo actualiza datos sino también
páginas Web). Por ello, generalmente deberemos contar con
opciones que permitan realizar actualizaciones manuales o
programadas en el tiempo (lo que reducirá significativamente el coste
de actualización de las páginas).
No sólo es importante el nivel de integración con el Web, sino que
también es importante el grado de interacción del usuario con la
misma. Generalmente las páginas Web proporcionan mecanismos de
selección de información personalizada, lo cual permite que los
usuarios accedan sólo a aquella información que precisan. Para ello,
es importante que exista un soporte de interacción que se obtiene a
través de código Java. Por lo tanto, cuanto mejor sea el soporte Java,
más se asegura la interacción y se amplía el rango de servicios que
puede proporcionar el servidor de datos.
Una de las mejoras realizadas como consecuencia de la integración
con la Red Global, es la de la posibilidad de permitir la compartición y
distribución de la información a lo largo de los servidores situados en
cualquier parte del mundo. Esto permitirá a las empresas disponer de
su información sea cuál sea el lugar del mundo en el que se
encuentre el departamento que la procesa. E, incluso, permitirá a las
empresas poder integrar sus bases de datos con sus proveedores o
clientes, de manera que podrán colaborar a nivel de servicios y
recursos de información, ganando en rapidez y fiabilidad. Para ello,
los servidores de datos deberán proporcionar los servicios de
intercambio de información, reglas de sincronización y todo un
conjunto de parámetros necesarios para que esta revolución en
cuanto a acceso global a la información sea posible.
2.4. HERRAMIENTAS DE ADMINISTRACIÓN
Avanzando un grado más en las capas de servicios que debe
proporcionar un servidor de datos, nos encontramos con las
herramientas que proporciona tanto al usuario administrador como al
cliente consumidor de los datos. De cara al administrador, las
herramientas deben proporcionarle un entorno amigable y sencillo de
manejar, que le permita orientarse a su trabajo y no preocuparse con
detalles de más bajo nivel, al tiempo que le permite realizar sus tareas
de la manera más rápida y simplificada posible. Indicar que cuanto
mayor sea el nivel de automatización de las tareas, menor será el
tiempo que tenga que dedicar a tareas generalmente repetitivas. Y
cuanto mayor sea el número de opciones configurables, mejor
servicio se podrá obtener de dichas tareas. La comodidad de acceso
a las herramientas es otro parámetro a tener en cuenta. Cuanta más
información tengamos a nuestro alcance, menor será el tiempo
empleado en acceder a la información necesaria para la
administración del servidor. No será extraño acceder a las opciones
de configuración y gestión a través de consolas que permitan la
integración de "snap-ins" o que, al menos, sirvan de pasarela entre las
múltiples utilidades disponibles. Dichas herramientas, además, deben
permitir la administración remota del servidor o servidores que estén a
cargo del administrador. De nuevo, insistir en el grado de
programación y automatización de tareas, ya que este mecanismo
proveerá de la creación de planes automáticos de realización de
tareas repetitivas de administración, lo que garantiza un alto grado de
seguridad, optimización, ahorro de tiempo y esfuerzo.
Como un componente fundamental de un servidor de datos, es el de
Optimización de la Base de datos y de las consultas. Cuanto más
efectiva sea la optimización del sistema, mayor velocidad adquirirán
las consultas y mejor rendimiento se obtendrá del servidor. Muchas
veces la velocidad no se encuentra en una máquina sobrada de
recursos, sino en aprovechar al máximo los recursos de los que
disponemos. Por lo tanto, cuanto mejor sea el soporte de optimización
para el administrador, mejor se podrá configurar el sistema, lo que
asegurará siempre un rendimiento máximo adaptado a las
necesidades de la empresa.
Las consultas y su proceso
El servicio más importante que proporciona un servidor de datos es el
del acceso a la información que almacena. El cómo recuperar y
actualizar dicha información es un proceso crítico del que depende en
mayor grado el éxito de este tipo de sistemas. El lenguaje que se
emplea en la actualidad es el SQL bajo el estándar ANSI SQL'92.
Esto, como comentamos anteriormente, garantiza que todo conjunto
de sentencias empleado para el acceso a una base de datos puede
ser empleado para cualquier tipo de servidor de bases de datos que
siga este estándar. Lo que independiza la necesidad de información
del cómo se encuentre almacenada.
Las herramientas actuales permiten encapsular el código SQL, de tal
manera que el usuario no tiene que conocer dicho lenguaje para
acceder a la información. Incluso, y gracias a los procedimientos
almacenados, es posible encapsular el código SQL dentro de la
propia base de datos, lo que da lugar a la petición de información
únicamente a través de un conjunto documentado de funciones
sencillas. Esto de cara a aplicaciones y usuarios simplifica el acceso a
la base de datos, y protege la arquitectura de la misma.
La optimización automática de consultas SQL es una nueva opción
que proporcionan los nuevos servidores de datos. Esto permite que
sea el propio servidor el que reconozca la mejor manera de recuperar
la información (optimización y asignación automática de índices, o
aprendizaje/ entrenamiento de consultas) que es lo que se conoce
como plan de ejecución de la consulta. Lo que en el caso de introducir
una sentencia SQL no optimizada por motivos de rapidez o
desconocimiento, permite acelerar al máximo el acceso a los datos.
Esto, junto con las capacidades multiproceso de los servidores,
permite que la ejecución de consultas complejas se convierta en una
operación rápida y de alto rendimiento.
Este apartado es muy importante de cara a la implementación de
aplicaciones OLTP (en las cuales es crítica la velocidad de
actualización de la información en línea) y en entornos
datawarehouse (en el que las consultas de recuperación de
información para la toma de decisiones dependen de consultas muy
complejas en proceso que devuelven valores calculados muy
concretos).
Por último, indicar en este apartado que será una opción de valor
añadido el incorporar servicios de datawarehouse, que permitan la
implementación de este tipo de arquitecturas en la empresa.
En el caso de aplicaciones OLTP.es muy importante el asunto de los
bloqueos de objetos de datos, pues el sistema gestor debe mantener
la integridad de la información que está siendo actualizada por
múltiples clientes al mismo tiempo. De no ser así, se podrían obtener
situaciones de registros fantasma, información de cálculo erróneo, e
información desactualizada. Habrá que estudiar cuál es el sistema
que ofrece un grado muy fino de bloqueo, pues cuanto menor sea el
nivel de bloqueo (se bloquea sólo lo justo) más usuarios podrán
acceder a los recursos al mismo tiempo. Un bloqueo a nivel de
columna permite a los usuarios acceder y modificar aquellas
columnas que no están siendo actualizadas por otros usuarios, dentro
de la misma fila. Un bloqueo a nivel de tabla paralizará temporalmente
las operaciones de aquellos usuarios que no tienen el acceso a dicho
recurso hasta que el operador termine su operación.
En este apartado, uno de los factores críticos es el del control de las
transacciones. Las transacciones son un conjunto de operaciones que
se realizan como una unidad de ejecución y que deben terminar con
éxito (en cuyo caso se actualiza la información implicada en todos los
pasos, se denomina "commit") o en fracaso (en cuyo caso el servidor
debe ser capaz de deshacer toda la operación para dejar la base de
datos en el último estado consistente, conocido como
"rollback"). Cuanto mayor sea el grado de recuperación y control de
las transacciones, mayor integridad se obtendrá en la base de datos.
Y este control se propaga en cuanto a transacciones distribuidas se
refiere, pues el que una transacción caiga en un determinado
servidor, debe implicar que todos los servidores implicados deben
echar atrás la operación errónea, lo cual puede resultar una operación
compleja y de envergadura. Además, en caso de caída los servidores
deben garantizar que todas las transacciones consideradas como
válidas son restauradas para garantizar la integridad de la información
en el momento del arranque de la máquina y antes de permitir el
proceso por parte de los usuarios (y es por ello por lo que los
servidores cuentan con el registro de LOG de transacciones).
2.5. PLATAFORMAS Y PROGRAMACIÓN
En este último punto comentaremos la importancia que tienen dos de
los parámetros relacionados con las plataformas disponibles para el
servidor y el grado de ampliación del mismo tanto de cara a su
implementación interna como en su capacidad de proporcionar API de
programación a los desarrolladores.
La escalabilidad y portabilidad del servidor será un factor a tener en
cuenta de cara a su adquisición o migración desde sistemas ya
existentes. Y ya no sólo de cara al motor del servidor sino de cara a
las plataformas de las herramientas de los clientes. Cuanto mayor sea
el rango de plataformas soportadas, tanto más universal será el
acceso al motor, lo que no limita a la empresa en cuanto a parque
tecnológico se refiere. En este punto, decir también que cuanto mejor
sea el soporte de migración y traspaso de información entre distintos
servidores, más se garantizará la integraci6n/migración de la
información ya existente, con el mínimo riesgo de pérdida de
información y el mínimo coste de implantación y desarrollo.
En cuanto al desarrollo, los servidores de datos deben proporcionar
las API necesarias para asegurar que los desarrollos que se lleven a
cabo puedan aprovechar los servicios de acceso y gestión de los
datos de la manera más eficiente y completa posibles. Y, además, no
deben limitar el desarrollo a la plataforma en la que se encuentra el
sistema, sino que debe ser capaz de dar soporte a los lenguajes
estándar de la Red como pueda ser Java, lo que garantizará una
integración total con los recursos de la Red.
2.6. EL SOPORTE HARDWARE NECESARIO
Lógicamente, sin un buen soporte hardware que proporcione los
factores de rendimiento necesarios para cumplir los objetivos de
acceso a la información, no podremos obtener las prestaciones
establecidas. En cuanto al procesador empiezan a aprovecharse al
máximo las arquitecturas SMP (Multiproceso simétrico). Los
servidores de datos serán capaces de distribuir la carga del análisis
dé las consultas, la ejecución de la programación de tareas y, como
no, el control de los accesos de múltiples usuarios al mismo tiempo.
Es requisito imprescindible contar con una buena cantidad de
memoria, pues una de las mejores maneras que, tienen los servidores
de proporcionar los datos de la manera más rápida posible es
mantener los sistemas de indexación, cursores y páginas caché en la
memoria del servidor. Lo que requiere de una enorme cantidad de
espacio libre. Ni que decir tiene que él disco duro es necesario que
disponga de almacenamiento de sobra si quiere ser capaz de albergar
varias bases de datos que son capaces de almacenar el nivel de
información diario (presente y futuro) que requiere el funcionamiento
de la empresa y sus reglas de negocio.
3. CONCLUSIONES
a. Ipv6
IPV6 aporta soluciones a los problemas de crecimiento de Internet.
Incorpora funcionalidades que mejoran su comportamiento en
aspectos de seguridad y configuración.
De acuerdo a los descrito anteriormente, se puede concluir que una
de las grandes diferencias entre el actual protocolo usado (IPv4) con
IPv6, es en la cantidad de combinaciones posibles que se pueden
obtener. En otras palabras, IPv6, ofrece 2^128 combinaciones, en
cambio IPv4, solo 2^32. Esto ampliaría enormemente el espectro de
objetos que puedan conectarse a la red, dando así, un mayor uso a
este medio y posiblemente descongestionar otros medios como son
las frecuencias de radio. IPv6 ofrece también, una notable mejoría
en disminuir el congestionamiento de las redes, como también
disminuir considerablemente el uso de NATs en redes, ya que estos,
ayudaban a ampliar las combinaciones posibles en IPv4.
b. Base de Datos
Las bases de datos forman el nucleó de las principales aplicaciones,
sitio web y servicios corporativos.
En todos los casos hay herramientas de gestión y control que
permiten verificar su funcionamiento y eventualmente corregirlo.
También se entiende que tiene una elevada capacidad y solidez
para administrar la información sin fallos ni errores.
4. RECOMENDACIONES
a. Ipv6
Favorecer la difusión y formación en Ipv6 en la comunidad
académica y empresarial.
Apoyar e impulsar las iniciativas del sector privado para el desarrollo
de nuevas redes, servicios y aplicaciones Ipv6.
Promover el uso de nuevas redes, servicios y aplicaciones Ipv6 en el
sector público, por parte de la administración pública.
Promover la implantación de Ipv6 por parte de las asociaciones
profesionales y empresariales.
b. Base de Datos
Las bases de datos sufren un desgaste del 3% mensual en
promedio, por lo que a fin de mantener un mayor porcentaje de
confiabilidad de los registros se deberá actualizar por lo menos 2
veces al año.
Elaborar un manual de uso donde se especifiquen las reglas de
captura de la base de datos. Ejemplo: abreviaturas, estandarización
de los registros, uso de mayúsculas, acentos, entre otros.
Identificar las diferentes variables que pudieran existir en un registro
para evitar su duplicidad.
Contar con una copia de respaldo que se ubique fuera de las
instalaciones de la empresa, a fin de garantizar su preservación en
caso de alguna eventualidad o desastre.
5. BIBLIOGRAFIA
a. Ipv6
http://es.wikipedia.org/wiki/IPv6
monografias .com/trabajos5/tipbases/tipbases.shtml
monografias .com/trabajos5/basede/basede.shtml
monografias.com/trabajos5/desor/desor.shtml
b. Base de Datos