Computação em Grid - EGI - LHC

download Computação em Grid - EGI - LHC

of 65

description

Introdução à Computação em Grid, baseado no projeto EGI. Instalacão e configuração de um cluster (site) para ser conetado ao Grid EGI.

Transcript of Computação em Grid - EGI - LHC

RELATRIO DE ATIVIDADES PROGRAMA DE CAPACITAO INSTITUCIONAL

CENTRO BRASILEIRO DE PESQUISAS FSICAS COORDENADOR DA COTA PCI: Ronald Cintra Shellard BOLSISTA: Dr. Edgar Rodolfo Rondn Sanabria TTULO DO PROJETO: Grid LHC no CBPF: Instalao e Configurao de um Cluster para o Grid EGEE Com Enfase na VO LHCb e Fusion do CBPF COLABORADOR DO PROJETO: Prof. Dr. Igncio Alfonso de Bediaga e Hickman PERODO DE VIGNCIA DA BOLSA: 01/04/2009 a 30/10/2009 N DO PROCESSO: MODALIDADE: DESENVOLVIMENTO TECNOLGICO INDUSTRIAL - DTI

1.- INTRODUO E HISTRICO reas de pesquisa tais como fsica de altas energias, seqenciamento gentico, previso de tempo, prospeco de petrleo, modelagem molecular e celular, reconstruo de imagens mdicas, fuso nuclear, medicamentos, etc.; requerem grande capacidade de processamento, anlise e armazenamento de uma grande quantidade de dados. Para poder satisfazer estas necessidades que surgiu um novo paradigma em computao de alto desempenho e disponibilidade, o qual requer uma arquitetura em Grade Computacional (Computing Grid). Atualmente, o projeto de computao em Grid, que est em ampla expanso e vem sendo utilizado por muitos centros de pesquisa, o projeto EGEE (Enabling Grids for EsciencE)[1]. Dentro deste projeto encontra-se o LCG (Large Hadron Collider (LHC) Computing Grid) [2], um dos principais grupos do pesquisa do EGEE no momento, dando suporte computacional aos experimentos ATLAS, ALICE, CMS e LHCb do LHC no CERN [3,7]. Deve-se lembrar que o WWW nasceu no CERN, chamado rotineiramente de web, o qual permite distribuir informao no mundo todo. Novamente, no CERN, foi criado o WLCG (Worldwide LHC Computing Grid) [2], como parte do EGEE, que permite distribuir capacidade de clculo e armazenamento no paradigma da Computao em Grade. O EGEE uma ampla infra-estrutura de Grid, multidisciplinar, constitudo por mais de 160 organizaes e disponibilizando recursos computacionais para centros de pesquisa da Europa e do mundo. O EGEE composto de pelo menos 250 sites, em 50 pases, com aproximadamente 100,000 CPUs disponveis, pelo menos para mais de 18.000 usurios, 24 horas por dia e 7 dias da semana. O CBPF (Centro Brasileiro de Pesquisas Fsicas) [5], no que se refere computao em grade, faz parte do EGEE participando no projeto LCG, tendo habilitado as VOs do LHCb, CMS, biomed e fusion. Quando o LHC entrar em funcionamento, sero produzidos aproximadamente 15 Petabytes (15 milhes de Gigabytes) de dados, anualmente. Centenas de cientistas ao redor do mundo precisaro acessar e analisar estes dados, de forma que a misso do projeto LCG conceder uma infraestrutura para tal tarefa. As grandes quantidades de dados e necessidades de computao nos experimentos do LHC sugerem que o tratamento de dados deva ser realizado em uma forma distribuda. Desta forma, distribuindo-se os dados, tem-se melhor vantagem dos recursos disponveis em todo os sites (resources) que fazem parte do Grid, permitindo assim, a colaborao na utilizao dos seus recursos. Os recursos disponibilizados pelo Grid, como CPUs, locais de armazenamento e softwares so acessveis, atravs de um conjunto padro de servios, disponvel para todos os experimentos e grupos de pesquisa, que fazem parte do Grid. O projeto de Computao em Grid do LHC foi projetado para fornecer todos esses recursos. O experimento LHCb est plenamente empenhado em participar do LCG, utilizando e contribuindo com softwares e projetos em comum; bem como a utilizao computacional plena da infraestrutura do grid do LCG. A computao distribuda (dados, gesto e manuteno) utiliza a infra-estrutura implantada pelo LCG, bem como base de servios prestados atravs do LCG. O CBPF faz parte do grupo de computao em grid do LCG, fazendo parte da VO (Virtual Organization) do LHCb, CMS, fusion e biomed [8]. A participao do CBPF no projeto LCG teve seu inicio no ano de 2006, sendo financiado pela FINEP. O principal objetivo deste projeto incluir o CBPF e seus grupos de pesquisa de altas energia (LAFEX) no LHC. Dentro de outros projetos encontra-se o aumento de CPUs, ate chegar a uns 1000 cores ate o final de 2010 e a incluso do Site do CBPF no LCG via o novo ROC_LA (Resource Operator Center of Latin America) criado rescentemente (01 de Outubro de 2009)[15].

2.- RESUMO DO PROJETO O grupo de sabores pesados do LAFEX/CBPF participou nas experincia de alvo fixo do Fermilab E791 e FOCUS e tem participado, desde 2001, da colaborao LHCb do CERN. Nesta colaborao, foram concludos, dentre outras atividades: Implantao do sistema GRID do CBPF, com 174 cores, funcionando no sistema LCG, inicialmente via ROC do CERN e agora via ROC_LA. At o final de 2009, pretende-se adicionar aproximadamente mais 200 cores e, ate 2010, mais 500 cores, totalizando 1000 aproximadamente. A simulao de eventos, bem como a anlise do altssimo volume de dados do LHCb, fazem necessria uma alta capacidade de computao e armazenamento, em um modelo de grade(grid) computacional. A capacidade computacional do Site CBPF visa atender demanda de docentes, pesquisadores e grupos de pesquisa do CBPF cujos projetos cientficos requeiram grande capacidade de processamento e armazenamento de dados, nestes projetos encontram-se os projetos que utilizao os cdigos do LHCb (Gaudi, Gauss, Boole, Brunel e Da Vinci [30]) instalados no Site CBPF. Para ter disponibilidade a esta demanda de servios a os usurios do CBPF, ser implementado um sistema de filas para a utilizao dos recursos e um sistema de disk array para o sistema de armazenamento de dados local. Ser instalado um sistema de monitoramento de temperatura interna dos perifricos das maquinas e externa, via browser. Se estudar e definir uma politica de segurana do Site CBPF contra ataques e invases. Utilizaremos a tecnologia de paravirtualizao para disponibilizar recursos com maior autonomia no dependentes de outros servios. Ser montado um curso de Computao em grade com enfase na instalao e configurao de um Site LCG/EGEE. 3.- OBJETIVOS

O objetivo principal do Grid CBPF dar suporte aos diferentes componentes de software, estruturados em camadas, em um ambiente de grade, tais como: processamento de dados (Gaudi, Gauss, Boole, Brunel e Da Vinci), anlise interativa (Bender e Panoramix) e computao distribuda (DIRAC e GANGA), na simulao de eventos das experincias do LHCb e CMS dentro do projeto LCG. Para tanto, necessria instalao e configurao do Site CBPF (cluster CBPF) com a topologia definida pelo LHCb, para dar suporte aos componentes de software. Disponibilizar um ambiente de servios computacionais baseados em um modelo de computao em grade distribudo. Gerenciar usurios e seus direitos, em um ambiente de grade no-centralizado, heterogneo e internacional. Atender s demandas de docentes, pesquisadores e grupos de pesquisas, cujos projetos cientficos requeiram grande capacidade de processamento e armazenamento de dados, no Site CBPF-LHCb/CMS. Estudo, utilizao e anlise via softwares do LHCb: Gaudi, Gauss, Boole, Brunel e Da Vinci. E seguidamente aprendizagem do software frontend GANGA.

4.- ATIVIDADES DESENVOLVIDAS As atividades desenvolvidas abarcam, desde o estudo da topologia do Grid LCG, at a implementao, configurao e instalao de middleware gLite, utilizado pelo LCG, no Site

CBPF. Utilizao dos softwares do LHCb disponveis no Grid e sua simulao no Grid. Simulaes utilizando o cdigo DaVinci e submisso de job ao Grid via GANGA. Estaremos enumerando as atividades desenvolvidas durante o perodo de trabalho, para depois estas serem descritas detalhadamente. Dentre estas atividades temos:

O Grid Computacional Arquitetura do LCG/EGEE Configurao e instalao do Site CBPF Produo e monitorao do Site CBPF Usando o Grid Submetendo jobs ao Grid, como exemplo cdigo Cintico Toroidal (Plasmas) Simulando com o cdigo DaVinci e GANGA no Grid

4.1.- O Grid Computacional O princpio da computao em Grid a agregao de recursos computacionais heterogneos (clusters de computadores, mainframe, at um simples computador) distribudos entre distintos centros de pesquisa. O conjunto computacional de cada centro de pesquisa, conectado Grid, chamado de Site. O conjunto de Sites, unidos como um s, forma um grid, e oferece grande capacidade de clculo, armazenamento, processamento, etc. Para fazer mais fcil a utilizao destas infra-estruturas distribudas, surge a necessidade de se estabelecer uma arquitetura global, que seja direcionada na prtica em uma srie de servios bsicos, em forma de middleware, os quais simplificaro o modo de desenvolver aplicaes. Estes servios bsicos devem oferecer, entre outras coisas, um acesso eficaz aos recursos computacionais, no sentido de compartilhar recursos individuais. O middleware adotado no EGEE o gLite [2]. A estrutura de suporte do Grid (EGEE) est organizado em ROCs (Regional Operation Centers). Todo site do Grid deve pertencer a um ROC, para que possa fazer parte do poder computacional do Grid. O ROC um centro de apoio s operaes e questes dos usurios dos sites pertencentes a ele. Tem ainda, como papel, dar suporte, ativar, desativar e gerenciar a qualidade de produo do conjunto de Sites. Na figura 1 mostramos os ROCs do Grid EGEE [6]. Por exemplo, pode-se ver que o CBPF est no ROC_LA [7]. Recentemente, o CBPF conquistou a confiana do EGEE, especificamente do ROC CERN, por seu bom trabalho e qualidade na prestao de servios aos usurios. Desde o inicio de Outubro de 2009, o CBPF, em conjunto com, Mxico (UNAM) e Colmbia (UNIANDES), esto a frente da administrao do ROC_LA (ROC da Amrica Latina).

Fig. 1: ROCs no Grid EGEE [6] (http://gridmap.cern.ch).

No Grid, os usurios esto organizados em VOs (Virtual Organizations). Uma VO um grupo de usurios com interesses e exigncias semelhantes, que sejam capazes de trabalhar em conjunto com os outros membros do grupo, compartilhando recursos (dados, software, conhecimentos, CPU, memria, etc); independentemente da sua localizao geogrfica. As VOs definem privilgios de uso e de acesso aos recursos do Grid. Alm disso, cada VO mantm sua prpria poltica de segurana e gesto de recursos. Uma lista de todas as VOs inscritas no EGEE est disponvel a partir do Portal CIC (Core Infrastructure Centres) [8]. necessrio ser um usurio de uma VO, antes que seja autorizada a submisso de um trabalho (job) ao Grid. At o momento h 174 VOs e 12,831 usurios no EGEE nas diferentes reas da cincia, como pode-se ver na tabela 1.

rea de aplicao Nmero de VOs Computer Science and Mathematics 5 Multidisciplinary VOs 27 Astronomy, Astrophysics and Astro-Particle 20 Physics Life Sciences 9 Computational Chemistry 4 Earth Sciences 9 Fusion 2 High-Energy Physics 39 Infrastructure 27 Others 32 TOTAL 174

Numero de usurios 23 1425 330 427 375 224 76 4831 2397 2723 12831

Tabela 1. Lista de VO e nmero de usurios no Grid EGEE [8].

VOs de Fsica de altas energias e Fsica nuclear, que inclui experimentos de aceleradores como no-aceleradores mostrado na tabela 2. VO name alice atlas babar belle calice cdf cms cppm desy dzero ghep gridpp hermes hone ific ilc ildg lattice.itep.ru Scope Global Selected Global Selected Global Global Global Global Global Selected Regional - France Regional - Germany/Switzerland Global Regional - Germany/Switzerland Global Regional - Germany/Switzerland Global Regional - South Western Europe Global Global Global Number of users 427 2072 26 26 17 410 917 26 24 138 22 40 2 6 31 90 56 Unknown*

lhcb Global Selected minos.vo.gridpp.ac.uk Global pheno Regional - UK/Ireland photon Regional - Russia superbvo.org Global supernemo.vo.euGlobal egee.org t2k.org Global uscms Global vo.agata.org Global vo.delphi.cern.ch Global vo.ipnl.in2p3.fr Regional - France vo.ipno.in2p3.fr Regional - France vo.irfu.cea.fr Regional - France vo.lal.in2p3.fr Regional - France vo.lapp.in2p3.fr Regional - France vo.llr.in2p3.fr Regional - France vo.lpnhe.in2p3.fr Regional - France vo.lpsc.in2p3.fr Regional - France vo.sbg.in2p3.fr Regional - France vo.sixt.cern.ch Global zeus Global

307 13 33 Unknown* 8 Unknown* Unknown* Unknown* 13 Unknown* 26 38 16 57 8 24 13 7 21 2 6

Tabela 2. VOs da rea de Fsica de altas energia e Fsica Nuclear [8].

As VOs que tratam de diferentes aspectos da investigao na rea de Fuso Nuclear a partir de simulao de mquinas at simulaes de Fsica de Plasmas mostrada na tabela 3. Nome da VO Homepage fusion http://grid.bifi.unizar.es/egee/fusion-vo/ rfusion http://vo.nfi.kiae.ru/pmwiki/pmwiki.phpTabela 3. VOs da rea de fuso [8].

Nmero de usurios 65 11

A produo por rea nas vrias reas disponveis no sistema LCG/EEGE, so mostradas na figura 2, a produo mostrada de Julho de 2008 a Junho de 2009 [9].

Fig. 2: Produo por rea de pesquisa de Julho de 2008 at Junho de 2009[9] (http://www3.egee.cesga.es/gridsite/accounting/CESGA/vodis_view.html).

Grids Internacionais: atualmente existem no mundo muitos projetos de Grid, mostramos a continuao:AP GRID D4Science DEISA EELA-2 EUAsiaGrid EU-IndiaGrid GridPP Open Grid Forum OGF-Europe Open Science Grid PRAGMA WINDS

EGEEEGI_DS

LCGNextGRID NorduGrid

A misso do Grid LCG construir e manter o sistema de armazenamento e a infraestrutura da anlise de dados de toda a comunidade da fsica de altas energias, como o LHC. O LCG faz parte do EGEE. O EGEE uma ampla infra-estrutura de Grid multidisciplinar, suportando mais de 120 organizaes e disponibilizando recursos computacionais para os centros de pesquisa da Europa e do mundo. O EGEE consta de 250 sites em 50 pases e mais de 68,000 CPU's disponveis pelo menos para uns 12811 usurios, 24 horas por dia e 7 dias da semana. Grid comerciais: AIMES, Avaki, Axceleon, GoGrid, HP, IBM, Platform Comp., etc. ActiveEon AIMES Avaki Axceleon Data Synapse Decker Consulting GmbH EmergenceTech GoGridGridSystems GridXpert GridwiseTech HP IBM Parabon Platform Computing Univa UD

Projetos de Middleware: assim como existem muitos projetos de Grids, tambm h uma variedade de projetos de middleware, como mostramos a continuao: Alchemi BioGrid Condor DCache DOE SciDAC ESnet GLOBUS gLite GRIDBUS GridSphere KnowARC NAREGI OGCE UNICORE

O gLite (pronunciado "gee-lite") faz parte do projeto LCG, foi produzido como parte do projeto EGEE e fornece um quadro para a construo de aplicaes em grids computacionais. 4.2.- Arquitetura do LCG/EGEE Aqui mostraremos brevemente a arquitetura do LCG/EGEE com seus principais elementos.

Segurana: conforme mencionado anteriormente, os grupos de usurios no LCG/EGEE esto organizados por VO's. Quando o registro de um usurio completado, ele pode acessar o LCG/EGEE. O Grid Security Infrastructure (GSI), do LCG/EGEE, permite autenticao segura e comunicao, atravs de uma rede aberta. O GSI baseado em criptografia de chaves pblicas, certificados X.509, e o protocolo de comunicao SSL (Secure Sockets Layer). Para utilizar os recursos do Grid, o usurio precisa ter um certificado digital X.509 emitido por uma Autoridade Certificadora (CA) confivel pelo LCG/EGEE. O usurio certificado, cuja chave privada protegido por uma senha, utilizado para gerar e assinar um certificado temporrio, chamado de proxy, que utilizada para a autenticao no grid. A autorizao de um usurio em um determinado recurso do Grid pode ser feita de duas maneiras diferentes. A primeira a mais simples e baseia-se no mecanismo de grid-mapfile. A segunda forma baseia-se no Virtual Organisation Membership Service (VOMS) e no mecanismo LCAS/LCMAPS, a qual permite uma definio mais detalhada de privilgios. Interface de usurio (UI): o ponto de acesso ao Grid LCG/EGEE (ver figura 2). Isto pode ser qualquer mquina, onde os usurios tenham uma conta pessoal, e onde os seus certificados esto instalados. A partir de uma interface, um usurio pode ser autenticado e autorizado a usar os recursos do LCG/EGEE. A UI fornece ferramentas CLI (command line interface) para realizar algumas operaes bsicas no Grid: - Lista todos os recursos adequados para executar uma determinada tarefa; - Apresenta trabalhos de execuo; - Cancela jobs; - Recupera a produo de jobs acabados; - Mostra o estado dos jobs apresentados; - Copia, reproduz e apaga arquivos do Grid.

Computing Element (CE): em termos de Grid, definir alguns dos recursos de computao localizada em um site (ou seja, um cluster, uma farm de computadores). O

CE inclui um Grid Gate (GG, chamado de Gatekeeper), que atua como uma interface genrica para o cluster; um Local Resource Management System (LRMS) (s vezes chamado de batch system). Alm do CE, h uma coleo de Worker Nodes (WNS), os ns onde os trabalhos so executados.

Fig. 3: Fluxo do Job no LCG/EGEE Grid. Existem duas implementaes GG em gLite 3.1: o LCG-CE, desenvolvido pelo EDG e utilizado em LCG-2, e o gLite-CE, desenvolvido pelo EGEE. Os Sites podem escolher o que instalar, alguns deles fornecem os dois tipos. O GG o responsvel por aceitar jobs e distribuir para os WNs para a execuo atravs do LRMS.

Fig. 4: Esquema de distribuio dos Tiers no LCG.

No gLite 3.1 os tipos de LRMS suportados so: OpenPBS/PBSPro, LSF, Maui/Torque, BQS e Condor, e com desenvolvimento em curso para suportar Sun Grid Engine. No site do CBPF temos instalado o LCG-CE e Maui/Torque.

Storage Element (SE): o SE prov um acesso uniforme a recursos de armazenamento de dados. O armazenamento em discos do SE pode ser em discos simples ou pode controlar servidores, os grandes arrays de discos ou fitas, baseadas em Mass Storage Systems (MSS). A maioria dos recursos de armazenamento so administradas por um Storage Resource Manager (SRM), um servio do middleware que fornece capacidades como uma transparente migrao de arquivos a partir de disco a uma fita, pinning de arquivos, reserva de espao, etc,. No entanto, diferentes SEs podem suportar diferentes verses de SRM. Existem uma srie de implementaes de SRM em uso, com diferentes capacidades. O Disk Pool Manager (DPM) bastante utilizado para pequenos SEs com armazenamento baseado apenas em discos, enquanto CASTOR projetado para gerenciar em grande escala sistemas MSS. No site CBPF temos implementado um sistema de SE baseado em DPM. Os tipos mais comuns de SE's correntemente pressentes em LCG/EGEE so:Type Classic SE DPM dCache CASTOR Resources Disk server Disk pool Disk pool/MSS MSS File transfer GSIFTP GSIFTP GSIFTP GSIFTP File I/O insecure RFIO No secure RFIO gsidcap Yes Yes SRM

insecure RFIO Yes

Workload Management: O objetivo do Workload Management System (WMS) aceitar jobs dos usurios, para atribuir-lhes o mais adequado CE, para gravar o seu estado e recuperar seus dados de produo. Jobs, a serem submetido, utilizam o Job Description Language (JDL), que especifica, por exemplo, o que executvel e com que parmetros ser executado. Alm disso, so especificados tambm os arquivos a serem copiados e recuperados dos WNs onde os jobs so executados, entrada de arquivos necessrios e todos os requisitos necessrios para rodar os jobs no site. A escolha da CE, para onde o trabalho ser enviado, feito por meio de um processo chamado jogo de deciso, que primeiro escolhe, entre todos os CEs, aqueles que preenchem os requisitos expressos pelo usurio e que so definidos no arquivo de entrada. Em seguida, escolhe o CE do mais alto posto (rank), que expressa a disponibilidade de uma CE (normalmente est em funo do nmero de jobs na fila). O fluxo de um job no Grid LCG/EGEE mostramos na figura 3.

O LCG est formado por Tiers, sendo o Site CBPF Tier 2 (T2). O esquema de distribuio dos Tiers no LCG e suas funes mostrado esquematicamente nas figuras 4 e 5.

Fig. 5: Esquema de centros dos Tiers no LCG e suas funes. 4.3.- Configurao e instalao do Site CBPF Neste relatorio apresentado detalhadamente os procedimentos de instalao e configurao de um site EGEE do WLCG para as VOs LHCb, fusion e biomed (ver Apndice A para ver descrio detalhada). Primeiramente comearemos com a instalao do sistema operacional, neste casso o Scientific Linux. Seguidamente passaremos instalao do sistema middleware usado no EGEE, que o gLite, na seguinte ordem: CE (computing element), SE (storage element), WNs (worker nodes) e UI (user interface). Logo ser descrito os passos necessrios para atualizao do sistema acada release do gLite. Mostraremos a criao de uma fila do batch system (TORQUE/Maui) local e usurios locais mapeados via NIS em todo o cluster, no nosso caso a fila ser chamada de focus. Site um termo utilizado no EGEE, que quer dizer cluster de computadores ligado ao Grid EGEE. Segundo as informaes no CIC (VO ID Cards do LHCb [8]), necessrios cumprir os seguintes requisitos para dar suporte VO do LHCb, como mostrado na tabela 4:Job CPU limit 2500 min/1000SI2K Job Wall Clock Time Limit 0 mn Job Scratch Space (GB) 10 GB Per-SE Storage Space (GB) 0 GB RAM per CPU core 32 bits (MB) 750 MB RAM per CPU core 64 bits (MB) 1000 MB Required virtual memory (MB) on 32 bits server 1500 MB Required virtual memory (MB) on 64 bits server 2000 MB Minimum number of job slots needed 0 Tabela 4. Requisitos para suportar VO do LHCb.

rea de software: Software Size (GB) Software Permissions 50 GB

e componentes CE (LCG-CE), SE (DPM), Portable Batch System (Maui/Torque), R-GMA (gLite-MON), UI e WN's (gLite-WN e Torque Client). Na figura 5 mostramos os componentes do Site CBPF.

Fig. 6: Componentes do Site CBPF 4.3.1.- Instalao do Sistema Operativo Scientific Linux nas mquinas CE, SE, WN e UI No Grid EGEE adotado o Scientific Linux (SL) como sistema operativo. O middleware utilizado no WLCG/ EGEE o gLite. A verso do gLite 3.1 suportado somente no SL4. Atualmente est-se fazendo um esforo, na verso 3.2 do gLite, para suportar outras distribuies de Linux como o Debian. O gLite 3.2 est em implementao somente para o SL5 tanto para 32 e 64 bits, enquanto que o gLite 3.1 suportado somente no SL4. No todos os aplicativos do gLite 3.1 como do 3.2 so suportados em arquiteturas de 64 bits (ver http://glite.web.cern.ch/glite/). No site do CBPF est instalado o SL4.8-x86_64 para todos os WN's e SL4.8-i386 para o CE, SE e UI, ate o momento o servio do gLite para o CE o lcg-CE e CREAM-CE, suportados somente para 32 bits. O SL4 instalado com pacotes mnimos, tabela 5.

Metapacote Base X windows system yum Editors Development tools Legacy software development Server configuration tools Administration tools

CE sim sim sim sim sim sim sim sim

SE sim sim sim sim sim sim no no

WN sim sim sim sim sim sim no no

UI sim sim sim sim sim sim no no

Tabela 5. Metapacotes necessrios.

Todos estes pacotes tem aproximadamente ocupam um espao de 1.8 GB. No necessrio uma instalao completa do SL, j que, consumiria muitos recursos da mquina e desnecessrios. No caso de precisar algum pacote, eles so instalados posteriormente. Segundo a tabela 3, para a VO do LHCb, o particionamento do HD, quantidade de memoria RAM, swap e rea de software para as mquinas do cluster do CBPF1 so: Partio/RAM RAM /boot / swap /data01 /opt/exp_soft /grid /home 8 GB 300 MB 80 GB 8 GB no no (NFS) no (NFS) no (est no /) CE 6 GB 300 MB 80 GB 6 GB Na odem de TB2 200 GB3 na ordem de TB4 no (est no /) SE 8 GB 300 MB 160 GB 16 GB no no (NFS) no (NFS) no (est no /) WN 2 GB 300 MB 25 GB 6 GB no no (NFS) no (NFS) Centenas de GB5 UI

Tabela 6. Particionamento de HD e memoria para a VO LHCb.1. Mquinas de 8 ncleos, 8 GB de RAM para os WNs e CE; 2 ncleos, 4 GB RAM para o SE; 2 ncleos e 2 GB RAM para a UI. 2. Depende do que vai ser feito, esta partio pode ser colocado em qualquer mquina, menos o CE.) 3. No casso do LHCb necessrio 50 GB. Neste diretrio tambm iro os softwares das outras VOs, aumentar o valor dependendo das especificaes das outras VOs. 4. Opcional, espao utilizado para fins locais. Esta partio pode ser colocado em qualquer mquina, menos o CE. 5. Depende da quantidade de usurios e que cdigos vo rodar.

necessrio alocar espao de HD em qualquer maquina do clusters para exportar via NFS para todas as mquinas do Cluster. Estas parties exportadas via NFS so:

/opt/exp_soft, lugar onde sero instalados todos os softwares das VOs, a instalao destes softwares feito por usurios autorizados da VO, como minimo de 50 GB para a VO LHCb. /grid, espao criado para armazenamento de dados dos usurios locais do Site CBPF. Este espao no requisito para as VOs suportadas.

A continuao mostramos resumidamente os passos seguidos na instalao e configurao do Site CBPF, no Apndice A mostrado com mais detalhe. Explicaremos tambm os passos de como configurar uma fila do TORQUE/Maui local e criao de usurios locais mapeados via NIS no cluster, no nosso caso a fila ser focus.

Primeiramente foi configurada as mquinas seguindo a topologia mostrada na figura 6. No clsuter do CBPF todas as mquinas fazem parte de uma mesma rede, onde necessrio que as mquinas CE, SE e UI tenham IPs vlidos e fixos. Pode-se configurar tambm uma intranet com IPs fictcios. No caso de configurar uma intranet, necessrio que as mquinas CE, SE e UI tenham IPs vlidos e os WNs IPs fictcios. Seguidamente foi instalado em todas as mquina o sistema operativo SL4.8 com os pacotes mnimos para no sobrecarregar a mquina com servios que no sero utilizados. Depois feito a atualizao do sistema utilizando os repositrios do Scientific LinuxCERN (SLC4.8) [10], onde so instalados pacotes necessrios para o correto funcionamento do middleware gLite. No CE (que tem como nome ce01) instalamos os pacotes do gLite: glite-BDII, lcgCE, glite-MON, glite-TORQUE_server e glite-TORQUE_utils do middleware gLite utilizando a ferramenta yum do SL, da forma:ce01# yum install lcg-CA glite-BDII lcg-CE glite-MON gliteTORQUE_server glite-TORQUE_utils

o metapacote glite-BDII armazena toda as informaes do Site e que ser consultada via LDAP, informaes como: nmero de CPU's do site, quantidade de memoria, nmero de jobs rodando, jobs em fila, VO's suportadas, etc.; algumas de estas informaes so mostradas em http://goc.grid.sinica.edu.tw/gstat/CBPF/ (figura 13). O metapacote lcg-CE instala pacotes referente ao computing element (CE), como GG (gatekeeper, etc.). O lcg-CA instala certificados (grid-mapfile) e o gliteTORQUE_* instala o PBS (TORQUE/Maui).

Depois de instalado os pacotes do gLite no ce01 necessrio configura-lo utilizando a ferramenta yaim do LCG [11]:ce01# yaim -c -s site-info.def -n BDII_site -n lcg-CE -n glite-MON -n TORQUE_server -n TORQUE_utils

para executar este comando necessrio definir variveis do Grid como: as VO's as quais o site vai pertencer, usurios e grupos a ser criados, caractersticas do site,

nmero de CPU's, quantidade de memoria, velocidade das CPU's, etc. Isto definido no arquivo site-info.def (Apndice B).

Uma vez configurado o CE, passamos a configurar o SE, na qual instalado os seguintes pacotes:se01# yum install glite-SE_dpm_mysql glite-SE_dpm_dis

onde utilizamos o sistema de armazenamento de dados DPM.

Logo utilizando a ferramenta yaim para configurarmos o SE:se01# yaim -c -s site-info.def -n SE_dpm_mysql -n SE_dpm_disk

de igual foma no site-info.def est definido informaes do SE (Apndice B).

Finalmente configurado os WN's (exemplo wn01):wn01# yum groupinstall glite-WN (no caso de 64 bits) wn01# yum install glite-WN (no caso de 32 bits) wn01# yum install glite-TORQUE_client lcg-CA

logo configuramos os WNs via yaim:wn01# yaim -c -s site-info.def -n glite-WN -n TORQUE_client

instalando o UIui# yum install glite-TORQUE_client lcg-CA glite-UI

Configurando o UI via yaim:ui# yaim -c -s site-info.def -n glite-UI -n TORQUE_client

No Apndice B mostrado todos os arquivos necessrios para rodar o yaim. 4.3.2.- Criando fila focus e usurios locais via NIS no Site CBPF. No Site do CBPF alem das filas do TORQUE/Maui para as VOs suportadas, h uma fila local para os usurios do CBPF, esta fila tem por finalidade alocar recursos do Site CBPF para os seus usurios locais, sendo possvel alocar uma porcentagem do poder computacional. As contas (/home) dos usurios est alocada na UI, estas contas mapeado para todo o cluster via NIS. Seguidamente explicaremos os passos para configurar o NIS e criao da fila focus no TORQUE/Maui. Configurando o NIS master server: Requer dos pacotes: ui# yum install yp-tools ypbind ypserv portmap

Sincronizar o tempo com um servidor de NTP, no Site CBPF nosso servidor de NTP a mquina ce01. Editar /etc/yp.conf: domain nos.10 server xxx.xxx.xxx.xxx Onde nos.10 o domnio do NIS, pode ser qualquer nome e xxx... o IP do servidor. Editar /etc/ypserv.conf: dns: no files: 30 xfr_check_port: yes * : * : shadow.byname : port * : * : passwd.adjunct.byname : port Editar /etc/sysconfig/network e acrecente a linha: NISDOMAIN="nos.10" Definir o nome do domnio NIS da forma: ui# domainname nos.10 ui# ypdomainname nos.10 Criar o arquivo /var/yp/securenets e enumerar as redes aos quais o NIS vai exportar: host 127.0.0.1 255.255.255.0 255.255.255.0 xxx.xxx.xxx.xxx zzz.zzz.zzz.zzz

Onde xxx... e zzz... so os IPs das redes. Assegure-se de estar rodando o servio "portmap": ui# service portmap start ui# chkconfig portmap on Iniciar o servio ypserv: ui# service ypserv start Checar se o servio est em modo listening: ui# rpcinfo -u localhost ypserv Voc ver o seguinte: program 100004 version 1 ready and waiting program 100004 version 2 ready and waiting

Inicialize os mapas do NIS: ui# /usr/lib/yp/ypinit -m Especifique o hostname local, Ctrl-D, y, deixe terminar. Levante os servios ypbind, yppasswdd, ypxfrd: ui# service ypbind start ui# service yppasswdd start ui# service ypxfrd start Defina os servios YP para rodar no boot-up: ui# ui# ui# ui# chkconfig chkconfig chkconfig chkconfig ypserv on ypbind on yppasswdd on ypxfrd on

Configurando o NIS client (exemplo wn20) Requer dos pacotes: wn20# yp-tools ypbind portmap Editar /etc/sysconfig/network e adicionar a linha: NISDOMAIN=nos.10 Editar /etc/yp.conf: domain nos.10 server xxx.xxx.xxx.xxx onde xxx.. o IP do servidor do NIS. Editar /etc/hosts e acrecente a linha: xxx.xxx.xxx.xxx ui.cat.cbpf.br Set NIS domain-name: onde xxx... o IP da UI. wn20# domainname nos.10 wn20# ypdomainname nos.10 Editar /etc/nsswitch.conf: passwd: shadow: group: files nis files nis files nis ui

Asegure-se de o portmap estar rodando: wn20# service portmap start wn20# chkconfig portmap on Inicializar o servio ypbind: wn20# service ypbind start wn20# chkconfig ypbind on Testar se est funcionando: wn20# rpcinfo -u localhost ypbind wn20# ypcat passwd Mapeando os usurios no Cluster Uma vez configurado o NIS procedemos a mapear os usurios locais da UI (/home) no cluster. Uma vez mapeados os usurios podero se autenticar em qualquer mquina do cluster. Na mquina master UI: Enumerar as contas de todos os usurios a ser mapeados no cluster em /etc/exports:ui# more /etc/exports /home/acorread /home/alvaro /home/augalves ... x.x.x.x/255.255.255.0(rw,sync,no_root_squash) x.x.x.x/255.255.255.0(rw,sync,no_root_squash) x.x.x.x/255.255.255.0(rw,sync,no_root_squash)

onde x.x.x.x a rede do cluster. Certifique-se que os servios NFS e portmap esto rodando: ui# ui# ui# ui# service portmap start chkconfig portmap on service nfs start chkconfig nfs on

Nas mquinas cliente (exemplo wn20): No arquivo /etc/auto.misc enumere todos os usurios a ser mapeados:wn20# more /etc/auto.misc acorread alvaro augalves ... -fstype=nfs -fstype=nfs -fstype=nfs ui:/home/acorread ui:/home/alvaro ui:/home/augalves

E no arquivo /etc/auto.master coloque a linha: wn20# more /etc/auto.master /misc /etc/auto.misc --timeout=5 fazer o link em cada mquina cliente e para cada usurio: wn20# ln -s /misc/ Inicialize os servios: wn20# wn20# wn20# wn20# wn20# wn20# service portmap start chkconfig portmap on service nfs start chkconfig nfs on service autofs start chkconfig autofs on /home/

Sempre quando um usurio for adicionado ao sistema, sera necessrio atualizar o NIS da forma: ui# make -C /var/yp e mapear o usurio no cluster como mostrado anteriormente. Criando a fila focus A fila focus do TORQUE/Maui criada na mquina onde est instalado o TORQUE-server, no casso do Site CBPF a mquina ce01. Podemos proceder de duas formas para a sua gerao: ce01# /usr/bin/qmgr 1 && other.GlueHostOperatingSystemName == "ScientificCERNSLC" && other.GlueCEPolicyMaxCPUTime > 120 && other.GlueCEPolicyMaxWallClockTime > 240 && other.GlueHostMainMemoryRAMSize >= 128 );

Aqui o executvel a ser submetido ao grid para rodar o test.sh, os arquivos de dados de entrada fileA e fileB o std.out e std.erro so arquivos onde mostrado se a execuo do job foi bem sucedida ou no. No rank informado que o job deve ser submetido em Sites que tenham CPUs livres, e em requirements definido as caractersticas e requisitos que deve ter o site onde o job vai ser executado, no exemplo pedimos que tenha pelo menos mais de uma CPU, mais de 128 MB de RAM e que tenha como sistema operativo o Slcientific Linux.

4.6.- VO LHCbO LHCb (http://lhcb.web.cern.ch/lhcb/) um experimento que est sendo desenvolvido para funcionar no CERN, no grande colisor de hdrons que est instalado a uma profundidade de 90 metros e deve comear a operar a finais de 2009. Seu objetivo estudar a Fsica de partculas que contm um quark b na sua composio. Em particular, pretende-se medir com preciso parmetros do Modelo Padro que esto relacionados com a violao da simetria CP nos decaimentos dessas partculas. Esta violao desempenha um papel muito importante para a assimetria entre matria e antimatria no universo. No comeo, partculas e antipartculas foram criadas em igual quantidade. Mas hoje h essencialmente matria. Todos os dados que sero gerados no LHCb sero armazenados e analisados numa estrutura de computao em Grid (WLCG). Para tal objetivo foi criado a VO do LHCb junto com um conjunto estruturado de cdigos (ver https://twiki.cern.ch/twiki/bin/view/LHCb/LHCbComputing e

http://lhcb-comp.web.cern.ch/lhcb-comp para mais detalhes) e Tiers. Na figura 13 mostramos a estrutura dos cdigos do LHCb. Para suportar a VO do LHCb necessario cumplir alguns requisitos, estes requisitos descrito no Operations Portal das VOs (http://cic.gridops.org/index.php?section=home). O Operations Portal tem como misso de garantir:

ser uma ferramenta de gesto e operaes ser um ponto de entrada para todos os integrantes do EGEE para suas necessidades operacionais gerenciar as informaes disponveis sobre as VOs do EGEE acompanhar e zelar o dia-a-dia das operaes sobre os recursos da rede e servios do Grid

4.6.1.- Tornando-se usurio da VO LHCb Para fazer parte como usurio da VO LHCb o procedimento o seguinte (procedimento semelhante para outras VOs) [8]: PASSO 1: Obter um certificado digital, reconhecido pela EGEE, a partir do seu RA (Registration Authority) local. Os RAs so pessoas autorizadas pelo CA (Certification Authority) para aprovar o pedido de certificados. Para o Brasil, pode-se encontrar toda a informao em https://brgridca.ic.uff.br/pub. PASSO 2: Colocar/Baixar o certificado no seu navegador web. Voc pode fazer isso normalmente em Preferncias -> Segurana -> Certificados. Tambm h a opo de importar diretamente o certificado para o browser acessando um link que ser enviado via e-mail pelo CA no momento da confirmao de seu pedido. Alguns navegadores aceitam apenas o formato .p12 para os certificados. Caso seja necessrio, pode-se executar o seguinte comando, para converter seu certificado do formato .pem (recebido do CA) para o formato .p12. Isto no ser necessrio, caso voc importe diretamente o certificado. # openssl pkcs12 -export -inkey userkey.pem -in usercert.pem -out my_cert.p12 PASSO 3: Pea o registro atravs da pgina de registros da VO LHCb (https://lcgvoms.cern.ch:8443/vo/lhcb/vomrs). Lembre-se de que voc precisa ter o seu certificado carregado no seu navegador, para poder acessar a pgina. PASSO 4: O gestor da VO LHCb receber automaticamente um e-mail com seu pedido. No sentido de se verificar que voc quem est solicitando, seu dever entrar em contato o responsvel pela VO, pelo telefone ou e-mail. Quando o processo for concludo voc receber um e-mail de confirmao. 4.6.2.- Habilitando o site para a VO LHCb Uma vez instalado e configurado o gLite no cluster, como mostrado na seo (4.3) necessrio publicar o site no EGEE. A publicao do site feito no GOCDB (https://goc.gridops.org/). Para poder acessar o formulrio e preencher os dados do site necessrio ter o certificado carregado no browser e cadastrado no GOCDB. O cadastro de certificados e sites no GOCDB feito pelo coordenador ou administrador da VO. Podemos

ter mais informao, como: e-mails, requisitos, etc. em https://cic.gridops.org/index.php? section=vo Uma vez publicado o site, depois de umas horas o site poder ser visto no GSTAT (http://goc.grid.sinica.edu.tw/gstat) na parte de teste. Pode-se submeter jobs ao site via SAM (https://cic.gridops.org/index.php?section=roc&page=samadmin) para ver se a configurao est correta e correger erros. Via SAM podemos fazer testes no site e ver a vitalidade do site. Para entrar em produo necessrio que todos os jobs de teste submetidos ao site tenham sucesso por 24 horas. Pode-se ver o estado dos jobs e do site em https://lcgsam.cern.ch:8443/sam/sam.py 4.6.3.- Cdigos da VO LHCb O conjunto de cdigos, figura 13, (gaudi, Gauss, Boole, Brunel e DaVinci) [30] instalado numa partio especfica (rea de software /opt/exp_soft) na mquina SE e distribuda para todo o Site via NFS para que desta forma todos os usurios do CE e WN's tenham acesso simultneo aos cdigos. Estes cdigos instalado no site por usurios que tem permisses e privilgios especiais.

Fig. 13: Distribuio esquemtica dos softwares do LHCb. Ganga um terminal de trabalho para a submisso e gesto de jobs implementado em Python. Ele foi desenvolvido para atender as necessidades do ATLAS e LHCb para uma ter interface do usurio no Grid, e inclui a base de suporte para configurar e executar aplicaes baseadas no framework do Gaudi. Na figura 14 mostramos o esquema do ganga [26].

Fig. 14: Distribuio esquemtica do Ganga.

4.7.- Usando GangaGanga um utilitrio amigvel para a administrao de jobs. Jobs podem rodar localmente ou sobre um nmero de batch systems e grids. Com Ganga a monitorao de jobs fcil, onde esteja rodando o job. Com Ganga pode-se mover o jobs para rodar em outra parte. Ganga a principal ferramenta de analise distribuda do experimento ATLAS e LHCb. Tem uma arquitetura modular sendo extensvel por qualquer um. Ganga um projeto open source. Ganga pode ser usando via linha de comando ou via entorno grfico. Para invocar o ganga necessrio rodar o comando ganga e depois mostrar um prompt, similar ao prompt do python. A continuao mostramos alguns exemplos de uso. ui$ ganga [In:] [In:] [In:] [In:] [In:] j = Job() j.application = Executable(exe='/bin/hostname') j.name = "MyTest" print j j.submit()

Espere um pouco at o job seja completado e logo veja no diretrio de sada [In:] j.status [In:] j.peek() [In:] j.peek('stdout')

A sintaxe para o peek muito flexvel, ver: [In:] help(j.peek) Agora submetemos jobs a um batch system. Para este exemplo copiamos um job similar ao do exemplo anterior. [In:] j2 = j.copy() [In:] j2.backend = Batch()#Como default no CBPF o PBS [In:] j2.submit() Se tem um certificado de grid, ento podemos submeter na grid o job: [In:] [In:] [In:] [In:] j3 = j.copy() j3.backend=Dirac()#Para o LHCb usamos o DIRAC, pode ser o LCG tambm. j3.submit() print j3

Como outro exemplo submeteremos um job do cdigo DaVinci, o qual ser dividido em vario subjobs dependendo a definio feita no ganga e dependendo do nmero de arquivos de dados de entrada. Pode-se criar um script em python para a submisso de jobs no ganga. O script que o chamamos de DaVinci_Ganga.py em python da forma:################################################################################ # ############################################################################ # # # # # # # Ganga commands: # # # # # # # # After submitted a job: # # # # j.peek() # # # # j.peek('stdout', 'tail -f') # # # # # # # # # # # ############################################################################ # ################################################################################ #=============================================================================== # Example ganga job submission file #=============================================================================== # # Set the compiler to 32 bit # setenv CMTCONFIG slc4_ia32_gcc34 # # Set ganga environment first with (e.g. ui) # > GangaEnv # Then choose your ganga version (default version is normally the best option) # # NB : This file is for the ganga 5 releases # # To submit you start ganga with the command "ganga" and then # at the ganga prompt type # # [In] 1 : ganga DaVinci_Ganga.py # # As an alternative you can also submit the job directly from

# the Unix prompt with the line # # [erondan@ui]~% ganga DaVinci_Ganga.py # # but in this way you will have the overhead of starting Ganga # for each job you submit. # #=============================================================================== # # For more information on ganga see http://cern.ch/ganga # # In particular, if you think you have found a bug, or you wish to suggest # some improvement in functionality, please report this at # https://savannah.cern.ch/projects/ganga/ # # For Dirac jobs, you can monitor their status at # http://lhcb.pic.es/DIRAC/Monitoring/Analysis # # For any ganga object used below, more detailed information can be found by # running help(XXX) at the ganga prompt. I.e. # > help(Dirac) # For more information on the Dirac backend # #=============================================================================== # Python modules import os dataset = {'type': 'BuKpipi' 'card': '_LFN_v31' DaVinciVersion = 'v24r0' my_homeDir = '/home/erondan' my_card my_dataset = dataset['card'] = dataset['type'] , }

my_fita = 'BuKpipi_LFN_DC06.py' my_ExtraOpt = '''DaVinci().DataType = "DC06" #other option is "2008" DaVinci().Simulation = True DaVinci().EvtMax = -1 EventSelector().PrintFreq = 1000 ''' print '-------------------------------------------------------------------------' print '> DST : ' + my_fita #print '-------------------------------------------------------------------------' print my_ExtraOpt #print '-------------------------------------------------------------------------' print ' ' my_pyFile = my_homeDir + '/cmtuser/DaVinci_' + DaVinciVersion + '/Phys/DaVinci/job/ DVBu2Kpipi.py' print ' ' print '-------------------------------------------------------------------------' #------------------------------------------------------------------------------# Make a new job object for DaVinci #------------------------------------------------------------------------------j = Job( application = DaVinci( version = DaVinciVersion ) ) #-------------------------------------------------------------------------------

#------------------------------------------------------------------------------# Define name for identifying the job (this name appears in the ganga job list) #------------------------------------------------------------------------------j.name = my_dataset + '_DV' + DaVinciVersion + my_card #------------------------------------------------------------------------------#------------------------------------------------------------------------------# The job configuration #------------------------------------------------------------------------------# Define the configuration file(s) to use #j.application.optsfile = [ File ( j.application.user_release_area + # '/DaVinci_' + j.application.version # + '/Phys/BdJPsiKs/v0r2/options/DVBd2JpsiKs.py' ) ] j.application.optsfile = [ File(my_pyFile), File(my_fita) ] # Extra options # Appended to the end of the main options to override default settings j.application.extraopts = my_ExtraOpt #------------------------------------------------------------------------------#------------------------------------------------------------------------------# Input data # Can either be specified in the main configuration files (DaVinci.py etc.) or # locally here as an LHCbDataset #------------------------------------------------------------------------------#os.system('cp ' + my_fita + ' usedType.py') #import usedType as source #fitas = source.fitas() #j.inputdata = LHCbDataset( files = fitas ) #os.system('rm -f usedType.py usedType.pyc') #------------------------------------------------------------------------------# Define a job splitter (very useful for many input data files) #------------------------------------------------------------------------------# Split jobs into 1 input file per job. max of 5 files in total j.splitter = SplitByFiles ( filesPerJob = 5, maxFiles =999999999999999 ) # This Splitter will query the Logical File Catalog (LFC) to find # at which sites a particular file is stored. Subjobs will be created # so that all the data required for each subjob is stored in # at least one common location. This prevents the submission of jobs that # are unrunnable due to data availability. # Useful when using the Dirac backend (see below) #j.splitter = DiracSplitter ( filesPerJob = 5, maxFiles = 5 ) #------------------------------------------------------------------------------#------------------------------------------------------------------------------# Job merging (merge output from sub-jobs from job splitter, if used) #------------------------------------------------------------------------------# No merging j.merger = None # Root file merging. See help( RootMerger ) for more details #j.merger = RootMerger( files = ['DVNtuples.root','DVHistos.root'], ignorefailed = True )

# SmartMerger - Able to handle various file formats (including root files) # See help( SmartMerger ) for more details #j.merger = SmartMerger( files = ['DVNtuples.root','DVHistos.root'], ignorefailed = True ) #------------------------------------------------------------------------------#------------------------------------------------------------------------------# Add here any special input files. Normally not needed. #------------------------------------------------------------------------------j.inputsandbox = [] #------------------------------------------------------------------------------#------------------------------------------------------------------------------# Add here any special output files. #------------------------------------------------------------------------------#j.outputsandbox = ['DVNtuples.root', 'JpsiKsHisto.root'] j.outputsandbox = [] #------------------------------------------------------------------------------#------------------------------------------------------------------------------# Define where to run #------------------------------------------------------------------------------# Submit to the grid. j.backend = Dirac() #------------------------------------------------------------------------------#------------------------------------------------------------------------------# Submit the job #------------------------------------------------------------------------------j.submit() #-------------------------------------------------------------------------------

Em este exemplo o cdigo a ser executado o BuKpipi.C, BuKpipi.h:#define Bukpipi_cxx #include "Bukpipi.h" #include #include #include void Bukpipi::Loop() { // In a ROOT session, you can do: // Root > .L Bukpipi.C+ // Root > Bukpipi t // Root > t.GetEntry(12); // Fill // Root > t.Show(); // Show // Root > t.Show(16); // Read // Root > t.Loop(); // Loop // // // // //

t data members with entry number 12 values of entry 12 and show values of entry 16 on all entries

This is the loop skeleton where: jentry is the global entry number in the chain ientry is the entry number in the current Tree Note that the argument to GetEntry must be:

// jentry for TChain::GetEntry // ientry for TTree::GetEntry and TBranch::GetEntry // // To read only selected branches, Insert statements like: // METHOD1: // fChain->SetBranchStatus("*",0); // disable all branches // fChain->SetBranchStatus("branchname",1); // activate branchname // METHOD2: replace line // fChain->GetEntry(jentry); //read all branches //by b_branchname->GetEntry(ientry); //read only this branch if (fChain == 0) return; Long64_t nentries = fChain->GetEntriesFast(); TFile *histofile = new TFile("histoB0JpsiKsDC06LL.root", "RECREATE"); histofile->cd(); TH1F *hlifeResol = new TH1F("hlifeResol", " Lifetime resolution", 50, -0.4,0.4); TH1F *hBlifetimeL0 = new TH1F("hBlifetimeL0 ","B lifetime (ps) ",100, 0 , 10 ); TH1F *hBlifetimeTrueL0 = new TH1F("hBlifetimeTrueL0","B lifetime (ps) True Tau ",100, 0., 10.); TH1F *hTrueBlifetimeL0 = new TH1F("hTrueBlifetimeL0","B lifetime (ps) True B ",100, 0 , 10 ); TH1F *hBmassNoCuts TH1F *hBmassL0 TH1F *hTrueBmassL0 = new TH1F("hBmassNoCuts","B mass",75 , 5200, 5350); = new TH1F("hBmassL0","B mass",75 , 5200, 5350); = new TH1F("hTrueBmassL0","B mass",75 , 5200, 5350); , 10 ); , 10 ); , 10 );

TH1F *hpTk = new TH1F("hpTk","pTJpsi All after L0", 50 , 0 TH1F *hpTkTrue = new TH1F("hpTkTrue","pTk True", 50 , 0 TH1F *hpTkFalse = new TH1F("hpTkFalse","pTk False", 50 , 0 Long64_t nbytes = 0, nb = 0; for (Long64_t jentry=0; jentryGetEntry(jentry); nbytes += nb; // if (Cut(ientry) < 0) continue; printf printf printf printf printf printf

("New B\n"); ("runNumber %d eventNumber %d\n",runNumber,eventNumber); ("B0_TRUEID %d B0 P %f \n",B0_TRUEID,B0_P); ("k_TRUEID %d k P %f \n",k_TRUEID,k_P); ("pp_TRUEID %d pp P %f \n",pp_TRUEID,pp_P); ("pm_TRUEID %d pm P %f \n",pm_TRUEID,pm_P);

hBlifetimeL0->Fill(B0_TAU); hBmassNoCuts->Fill(B0_MM); if (L0Decision > 0 ){ hBmassL0->Fill(B0_MM); hpTk->Fill(k_PT / 1000.); if (abs(B0_TRUEID)==521 ){ hTrueBmassL0->Fill(B0_MM); hTrueBlifetimeL0->Fill(B0_TAU); hBlifetimeTrueL0->Fill(B0_TRUETAU); hlifeResol->Fill(B0_TAU-B0_TRUETAU); hpTkTrue->Fill(k_PT / 1000.); printf ("%lf %lf %lf %lf %lf %lf\n", pp_TRUEP_X,pp_TRUEP_Y,pp_TRUEP_Z,

pm_TRUEP_X,pm_TRUEP_Y,pm_TRUEP_Z); }//if (abs(B0_TRUEID)==521) else{ hpTkFalse->Fill(k_PT / 1000.); }//else from if (abs(B0_TRUEID)==521) }//if (L0Decision > 0 ) // if (Cut(ientry) < 0) continue; } histofile->Write(); }

No arquivo DVBu2Kpipi.py definido as variveis de entrada para o codigo DaVinchi:# Variable used just to submition control MassWindow = "ADAMASS('B+') K+ pi+ pi-]cc"] # ***Cuts Bu2Kpipi.MotherCut = "(VFASPF(VCHI2)2) & (BPVDIRA>0.) & (PT>3000*MeV) & (MAXTREE((('pi+'==ABSID) | ('K+'==ABSID)) ,PT)>1600*MeV)" #Bu2Kpipi.MotherCut = "(BPVIPCHI2()100) & (VFASPF(VCHI2)0.035)", "pi+" : "(MIPDV(PRIMARY)>0.035)"} Bu2Kpipi.OutputLevel = outputLevel SeqBu2Kpipi.Members += [Bu2Kpipi] ######################################################################## # DecayTreeTuples ######################################################################## from Configurables import DecayTreeTuple # ***Tools of DecayTreeTuple from Configurables import TupleToolTrigger, from Configurables import TupleToolMCBackgroundInfo, from Configurables import TupleToolKinematic, from Configurables import TupleToolPrimaries, from Configurables import TupleToolMCHierarchy, from Configurables import TupleToolTrackInfo,

TupleToolMCTruth TupleToolGeometry TupleToolPropertime TupleToolEventInfo TupleToolPid TupleToolVtxIsoln

Tuple = DecayTreeTuple("Bu2KpipiTuple") Tuple.addTool( PhysDesktop() ) Tuple.InputLocations = ["Phys/Bu2Kpipi"] #Tuple.Context = "HLT" Tuple.Decay = "[B+ -> ^K+ ^pi+ ^pi-]cc"; Tuple.Branches = { "k" : "[B+ -> ^K+ pi+ pi-]cc" ,"pp" : "[B+ -> K+ ^pi+ pi-]cc" ,"pm" : "[B+ -> K+ pi+ ^pi-]cc" ,"B" : "[B+]cc : [B+ -> ^K+ ^pi+ ^pi-]cc" } Tuple.ToolList = [ "TupleToolTrigger" , "TupleToolMCTruth" , "TupleToolMCBackgroundInfo" , "TupleToolGeometry" , "TupleToolKinematic" , "TupleToolPropertime" , "TupleToolPrimaries" , "TupleToolEventInfo" #, "TupleToolMCHierarchy" , "TupleToolPid" , "TupleToolTrackInfo" , "TupleToolVtxIsoln" #, "TupleToolTISTOS" ] ##################################################################### ##################################################################### ## runNumber, eventNumber

Tuple.addTool(TupleToolEventInfo) Tuple.TupleToolEventInfo.OutputLevel = outputLevel ## Trigger: L0Decision , HltDecision, ...(verbose) Tuple.addTool(TupleToolTrigger()) Tuple.TupleToolTrigger.FillL0 = True Tuple.TupleToolTrigger.FillHlt = True Tuple.TupleToolTrigger.VerboseL0 = True Tuple.TupleToolTrigger.VerboseHlt1 = True Tuple.TupleToolTrigger.VerboseHlt2 = True Tuple.TupleToolTrigger.OutputLevel = outputLevel ## IP, IPChi2, DIRA, ## Vertex: position, x, y, z, Chi2, nDoF ## Flight Distance: FD, FDChi2, FDPV, FDPVChi2 Tuple.addTool(TupleToolGeometry) Tuple.TupleToolGeometry.OutputLevel = outputLevel ## p, pt, momentum, referencePoint, measuredMass, measuredMassErr Tuple.addTool(TupleToolKinematic) Tuple.TupleToolKinematic.OutputLevel = outputLevel ## Propertime: pt/timeUnit, ept/timeUnit, chi2 Tuple.addTool(TupleToolPropertime) Tuple.TupleToolPropertime.OutputLevel = outputLevel ## (tuple->farray): PVX, PVY, PVZ, nPV ## PVXERR, PVYERR, PVZERR, nPV ## PVCHI2, PVNDOF, PVNTRACKS, nPV Tuple.addTool(TupleToolPrimaries) Tuple.TupleToolPrimaries.OutputLevel = outputLevel ## Pid: CombDLLe, CombDLLmu, CombDLLk, CombDLLp Tuple.addTool(TupleToolPid) Tuple.TupleToolPid.OutputLevel = outputLevel ## Track: type, chi2, nDoF, probChi2, GhostProbability, CloneDist Tuple.addTool(TupleToolTrackInfo) Tuple.TupleToolTrackInfo.OutputLevel = outputLevel ## nCompatibleIP, nCompatibleDeltaChi2, nCompatibleChi2 Tuple.addTool(TupleToolVtxIsoln) Tuple.TupleToolVtxIsoln.OutputLevel = outputLevel ## L0 and Hlt1 and Hlt2: decision, tis, tos #Tuple.addTool(TupleToolTISTOS) #Tuple.TupleToolTISTOS.OutputLevel = outputLevel ## MC: PID, nbAss, P, originVertex, EndVertex, Tau(Lifetime) ## *********************************************************** ## * Note that the tau(lifetime) is extracted of the particles ## * that have a MC link. It's different of the "Gen Lifetime" ## * of the old AnalysisNtuple. In the old "Gen Lifetime" a ## * the particles used are adquired directly from MCParticles ## * container. >>>>>>>> CREATE A TOOL TO REPRODUCT THIS PLOT ## *********************************************************** #Tuple.addTool(TupleToolMCTruth) #Tuple.TupleToolMCTruth.StoreAssociationNumbers = True #Tuple.TupleToolMCTruth.StoreKineticInfo = True #Tuple.TupleToolMCTruth.StoreVertexInfo = True #Tuple.TupleToolMCTruth.StorePropertimeInfo = True #Tuple.TupleToolMCTruth.OutputLevel = outputLevel MCTruth = TupleToolMCTruth() MCTruth.ToolList = ["MCTupleToolKinematic","MCTupleToolHierarchy" ] Tuple.addTool(MCTruth) Tuple.TupleToolMCTruth.OutputLevel = outputLevel ## MC: Background Category Tuple.addTool(TupleToolMCBackgroundInfo)

Tuple.TupleToolMCBackgroundInfo.OutputLevel = outputLevel ## MC: motherID, motherKey, ## gd_motherID, gd_motherKey, ## gd_gd_motherID, gd_gd_motherKey, #Tuple.addTool(TupleToolMCHierarchy) #Tuple.TupleToolMCHierarchy.UseChi2Method = False #Tuple.TupleToolMCHierarchy.OutputLevel = outputLevel SeqBu2Kpipi.Members += [Tuple]

e dados de entrada, que encontram-se nos Tiers 1, no caso do LHCb nos computadores do CERN. O caminho de estes dados de entrada (arquivos) esto definidos em BuKpipi_LFN_DC06.py:#-- GAUDI jobOptions generated on Wed Aug 5 19:30:45 2009 #-- Contains event types : #-12103022 - 3815 files - 1895857 events - 727.52 GBytes from Gaudi.Configuration import * EventSelector().Input = [ " DATAFILE='LFN:/lhcb/production/DC06/phys-v4lumi2/00002140/DST/0000/00002140_00000011_5.dst' " DATAFILE='LFN:/lhcb/production/DC06/phys-v4lumi2/00002140/DST/0000/00002140_00000012_5.dst' " DATAFILE='LFN:/lhcb/production/DC06/phys-v4lumi2/00002140/DST/0000/00002140_00000013_5.dst' " DATAFILE='LFN:/lhcb/production/DC06/phys-v4lumi2/00002140/DST/0000/00002140_00000015_5.dst' " DATAFILE='LFN:/lhcb/production/DC06/phys-v4lumi2/00002140/DST/0000/00002140_00000016_5.dst' " DATAFILE='LFN:/lhcb/production/DC06/phys-v4lumi2/00002140/DST/0000/00002140_00000018_5.dst' " DATAFILE='LFN:/lhcb/production/DC06/phys-v4lumi2/00002140/DST/0000/00002140_00000019_5.dst' " DATAFILE='LFN:/lhcb/production/DC06/phys-v4lumi2/00002140/DST/0000/00002140_00000020_5.dst' " DATAFILE='LFN:/lhcb/production/DC06/phys-v4lumi2/00002140/DST/0000/00002140_00000021_5.dst' " DATAFILE='LFN:/lhcb/production/DC06/phys-v4lumi2/00002140/DST/0000/00002140_00000023_5.dst' " DATAFILE='LFN:/lhcb/production/DC06/phys-v4lumi2/00002140/DST/0000/00002140_00000024_5.dst' " DATAFILE='LFN:/lhcb/production/DC06/phys-v4lumi2/00002140/DST/0000/00002140_00000025_5.dst'

TYP='POOL_ROOTTREE' OPT='READ'", TYP='POOL_ROOTTREE' OPT='READ'", TYP='POOL_ROOTTREE' OPT='READ'", TYP='POOL_ROOTTREE' OPT='READ'", TYP='POOL_ROOTTREE' OPT='READ'", TYP='POOL_ROOTTREE' OPT='READ'", TYP='POOL_ROOTTREE' OPT='READ'", TYP='POOL_ROOTTREE' OPT='READ'", TYP='POOL_ROOTTREE' OPT='READ'", TYP='POOL_ROOTTREE' OPT='READ'", TYP='POOL_ROOTTREE' OPT='READ'", TYP='POOL_ROOTTREE' OPT

... (continua) No arquivo de submisso do ganga foi definido que cada job tenha como mximo 5 arquivos de entrada. No caso de cem arquivos de entrada teremos 20 jobs. A submisso feita no grid via batch system DIRAC, a submisso feita da forma: ui$ ganga [In:] ganga DaVinci_Ganga.py [In:] j.status

4.8.-VO fusionA VO fusion do EGEE consta dos seguintes parceiros (membros-scios) [10]:

BIFI, CIEMAT e UCM (Espanha) CEA-Cadarache (Frana) EFDA (EU) ENEA (Itlia) KISTI e NFRC (Coreia) Kuchatov Institute (Rssia)

Para obter mais informao dos procedimentos de como se tornar um parceiro da VO fusion pode entrar em contato com: Francisco Castejn Magana, [email protected], (EGEE Fusion coordinator) Isabel Campos Plasencia. [email protected], (FUSION VO manager) Technical fusion VO supor0t, ([email protected]) Todo site, conectado ao Grid, est ligado a alguma VO, da qual parceiro ou colaborador. Pode-se tambm habilitar, no site, jobs de outras VOs, sem a necessidade de ser um colaborador ou parceiro daquela VO. No Grid EGEE h atualmente 58 sites habilitando a VO fusion, tendo sua disposio um grande potencial computacional, como pode-se ver na figura 15. Nesta figura, a primeira coluna mostra o total de CPUs do site, a segunda CPUs livres. Esta ltima, pode significar que o site est sendo utilizado por outras VOs. A terceira coluna mostra o total de jobs que esto rodando da VO consultada. Na quinta, o total de jobs na fila e na sexta o nome do site. Pode-se ressaltar que, nesta figura, os dados mostrados pela consulta so instantneos, podendo variar ao longo do tempo, medida que novos sites sejam incorporados no Grid, ou aumentem o nmero de CPUs [28]. No caso do CBPF, mostrado na segunda linha, com total de 152 CPUs, 77 jobs rodando e 3 jobs na fila da VO fusion.

Fig 16: Produo do Site CBPF at Outubro de 2009.

Fig 15: Sites que habilitam a VO fusion no EGEE.

Como foi mencionado acima, o Site CBPF tem habilitado as VOs LHCb, fusion, biomed e CMS. At o momento temos nmeros significativos no que se refere produo, mostramos na figura 16. Pode-se ver, na figura 16, que foram executadas 4519 jobs, da VO fusion, at o momento (28 de Outubro de 2009). Deve-se salientar que a VO fusion foi habilitada no Site CBPF no final do ms de Maro de 2009 e o Site CBPF est em produo desde Agosto de 2008.

Na figura 17 mostra-se a percentagem da utilizao do site CBPF pelas VOs habilitadas, desde Novembro de 2008 at Outubro de 2009. Pode-se ver que a VO fusion tem uma utilizao de 10.1% do poder computacional do site CBPF durante este perodo de tempo [11].

Fig 17: Produo das VOs habilitadas no site CBPF[11] (http://www3.egee.cesga.es/gridsite/accounting/CESGA/egee_view.php).

Mais informao pode ser encontrada nas Refs. [11,12,13].

4.8.1.- Tornando-se usurio da VO fusionPara fazer parte como usurio da VO fusion o procedimento o mesmo ao mostrado na seo (4.6) a diferencia do passo 3 que seria: Pea o registro atravs da pgina de registros da VO fusion (https://swevo.ific.uv.es:8443/voms/fusion/Login.do). Lembre-se de que voc precisa ter o seu certificado carregado no seu navegador, para poder acessar a pgina.

4.8.2.- Habilitando o site para a VO fusionPara habilitar a VO fusion necessrio um cluster, com algumas CPUs. O nmero de CPUs varia segundo a necessidade do projeto, parte financeira, etc. Pode-se ver na figura 3, sites com at 10 CPUs e outros com aproximadamente 2500 CPUs. Se seu cluster ainda no est conetado no Grid, o primeiro passo entrar em contato com o supervisorcoordenador ou administrador da VO, para que lhe sejam passados os procedimentos. Pode-se entrar em contato com os administradores do site CBPF que fazem parte do ROC_LA, os quais esto aptos em colaborar (https://wiki.roc-la.org/RocLA) [15]. Para que um site seja validado e entre no Grid necessrio que o site passe por alguns testes (feitos pelo ROC ao qual pertencer o site). Uma vez completados com sucesso os testes, o ROC validar o site e este logo ser liberado no Grid, disponibilizando recursos do site para os usurios das VOs habilitadas. Para habilitar a VO fusion necessrio que o site possua os seguintes componentes: CE (Computing Element), SE (Storage Element), WNs (Work Nodes) e UI (User Interface). Existem outras VOs que requerem mais componentes, como por exemplo a VO ALICE

(Experimento do LHC) que requer uma VOBOX [16]. Na VO fusion os WNs podem ser Pentium IV com 512 MB de RAM como mnimo. recomendvel 1 GB por CPU [19]. Durante a execuo de um job necessrio de 10 GB de espao temporrio (em disco) para alocao de dados, mas recomenda-se 20-30 GB. O tamanho do SE depende das necessidades, se for gerar grande quantidade de dados necessrio uma capacidade de armazenamento na ordem de TBs. recomendvel que o CE seja uma mquina servidora, rpida, com aproximadamente 4 GB de RAM e 100 GB de disco. No cluster, deve-se instalar o gLite [20], middleware do EGEE para criar uma camada de abstrao, para que, desta forma, o acesso se torne mais simples e transparente. No ser mostrado aqui o procedimento de instalao, j que um assunto muito tcnico. No Apndice B mostrado o arquivo de configurao do yaim.

4.8.3.- Softwares da VO fusionOs softwares disponibilizados na VO fusion so mostrados no MoU (Memorandum of Understanding) [19]. Para poder ter acesso e colaborar com estes cdigos necessrio entrar em contato com o administrador-supervisor da VO, mostrado na seo (3). Os cdigos do Grid variam de tamanho segundo as VOs. Por exemplo, no caso do LHCb os cdigos so muito complexos, de algumas centenas de MBs de tamanho. Rodar jobs com executveis grandes no conveniente no Grid, j que consumiria muita banda de rede. Para cdigos menores, aceitvel o executvel ser transportado junto com o job para o Site onde ser rodado. Depois de terminada a execuo, este ser apagado. No caso de cdigos grandes, as fontes so armazenadas em cada site. A instalao destes cdigos feito somente por usurios autorizados da VO. Na figura 18 mostramos todos os cdigos da VO fusion.

Fig 18: Cdigos disponiveis na VO fusion (http://appdb.eu-egee.org/).

Na seo (7) ser mostrado como um pequeno cdigo rodado no Grid, na qual o executvel ser transportado junto ao job. A seguir, mostra-se os cdigos disponveis na VO fusion. EUFORIA (EU Fusion fOR Iter Applications)(http://www.euforia-project.eu/EUFORIA) um projecto financiado pela Unio Europia, que ir fornecer um quadro global e infraestrutura para a simulao de transporte e turbulncia em plasmas, interligando-se ao Grid EGEE. O projeto EUFORIA ir melhorar as capacidades de modelagem para o ITER no mbito das simulaes, isto ser conseguido no grid EGGE via VO fusion. Isso aumenta fortemente as capacidades integradas de modelagem de plasmas de fuso e ao mesmo tempo, fornece infra-estrutura de computao e ferramentas novas para a comunidade da fuso em geral. Os seguintes cdigos tm sido identificados com um interesse potencial para a sua adaptao:

BIT1 Kinetic 1D3V (1D in usual and 3D in velocity space) code for simulation of the plasma edge. CENTORI Fully toroidal two-fluid, electromagnetic turbulence simulation code. COREDIV Transport of energy code, main ions and impurity ions in the core and the scrape of layer regions. EIRENE Kinetic neutral particle and line radiation transport code. ELMFIRE Gyro-kinetic full-f particle code, with mostly global emphasis.a ERO Gyro-kinetic code for impurity transport in plasma. ESEL Turbulence and profile evolution code at the outboard mid-plane in the SOL, using a fluid (ESEL) and gyrofluid (GESEL) approach. GEM Gyrofluid code (GEM is local, GEMX is nonlocal, same infrastructure, similar scheme and programming, somewhat differently formulated equations). GENE Nonlinear gyrokinetic code to investigate plasma turbulence. ISDEP Kinetic theory of transport code based on Langevin Equations. SOLPS Two codes (B2-Eirene) tightly coupled together based code. TECXY 2D multifluid plasma and impurity transport in the tokamak edge simulating code. TYR Drift Alfven plasma fluid turbulence and transport in flux-tube geometry code.

4.8.4.- Utilizando o Grid, VO fusion necessrio ter uma conta em uma mquina UI, de onde sero submetidos os jobs ao Grid, e estar associado VO fusion (seo (4)). Uma vez logado na UI, o certificado do usurio deve estar devidamente configurado. Copie seu certificado na sua conta (/home/usuario/.globus), geralmente tem o formato .p12, se for este o caso, necessrio transformar de formato para .pem, com o seguinte comando:

openssl pkcs12 -clcerts -nokeys -in -out ~/.globus/usercert.pem openssl pkcs12 -nocerts -in -out ~/.globus/userkey.pem chmod 600 ~/.globus/userkey.pem

Para usar o Grid, um usurio deve-se autenticar. Esta autenticao feita via proxy, que expira, normalmente, entre 12 a 24 horas, mas que pode ser aumentada dependendo da VO. Esta autenticao feita via Certificado Digital. Uma proxy permanece vlida enquanto o job rodar e fornece a autorizao para utilizao dos recursos a que se tem direito. Podese criar dois tipos de proxy: o primeiro de curto prazo, queles que residem na UI com um tempo mximo definido pela VO. Por exemplo, para o LHCb de 168 horas e para a VO fusion 72 horas. O segundo tipo de proxy, de longo prazo, aqueles que residem no Resource Broker (RB) ou Workload Management System (WMS) [21] e pode durar, em princpio, at uma semana (podendo ser aumentada). Para situaes de testes, necessrio uma proxy curta mas, para casos que precisam de longos perodos de computao, necessrio uma proxy de longo prazo, juntamente com o de curto prazo. Criando uma proxy de curto prazo, 72 horas, na VO fusion:

Criando uma proxy de longo prazo, 25 dias no servidor de proxys proxyegee.bifi.unizar.es:

Depois de se criar uma proxy, h condies de se submeter jobs no Grid.

Submisso de jobs 1: o Job Description Language (JDL) usado para descrever os jobsque sero executados no Grid. O JDL est baseado no CLASSified Advertisement language (ClassAd) definido pelo projeto Condor [22]. O JDL usado para especificar as caratersticas ClassAd) [22] de um job, s quais sero usadas durante o processo de escolha dos recursos a satisfazer os requerimentos do job (quantidade de memria, nmero de CPUs, velocidade, suporte a MPI (Message Passing Interface), etc.). Todos os recursos de um site so publicados via LDAP [23]. Estes recursos podem ser definidos no JDL para filtrar os recursos necessrios para a execuo do job. Por exemplo, se quisermos saber que um site suporta MPI, pode-se fazer uma consulta da seguinte forma:

Como exemplo, pode-se rodar um pequeno cdigo FORTRAN (figura 19), o qual ser submetido via JDL ao grid. No arquivo JDL files.jdl, figura 20, especifica-se qual o executvel a ser rodado no Grid, o qual o chamamos de exe_files. Os arquivos alfdata.txt e alfdata2.txt so os arquivos de entrada. No arquivo std.out armazenado o output padro do job. Caso ocorram erros durante a execuo, ser

informado no arquivo std.err. Como requerimento define-se que o job seja executado em qualquer site do Grid. Quem se encarrega de escolher o melhor site para sodar o WMS. Podemos tambm escolher o site, no arquivo files.jdl, onde temos duas linhas comentadas. Se descomentarmos alguma das linhas, o job ser rodado no site definido, quer seja no site do CBPF, ou no IFCA (ver figura 8).

Fig 19: Cdigo FORTRAN.

Fig 20: Cdigo JDL.

Antes de rodar, necessrio se verificar quais sites so compatveis com nossos requerimentos, definidos em files.jdl. Pode-se consultar da seguinte forma:

Pode-se obter maiores informao do site onde ser rodado o job, da seguinte forma:

Pode-se ver a submisso de um job na grid na figura 21. No arquivo jobID ser gerado o job ID para o job. Uma vez submetido, o WMS escolher o melhor site para o job rodar. Pode-se consultar o andamento de execuo do job (figura 22). V-se que o job foi submetido no site egeece02.ifca.es, definido pelo WMS. Obtm-se maiores informaes com o comando glite-wms-jobFig 21: Submisso de Job no Grid.

logging-info -i jobID, que mostrar passo a passo a execuo do job. H comandos teis, como por exemplo cancelar o job, etc. (figura 23).

Fig 22: Estado de execuo do job.

Fig 23: Comandos teis.

Uma vez terminado de rodar o job, mostra-se na sada padro, o seguinte:

Para se obter as sadas, dados gerados do job, pode-se fazer o seguinte, a partir da conta do usurio:

Nesta ltima figura, pode-se ver os dados de sada, na conta do usurio.

Submisso de Jobs Cdigo 2: Tambm como exemplo, pode-se rodar um cdigo quetem uma estrutura de arquivos com dados de entrada e dados gerados, chamado de cdigo Cintico Toroidal [24,25,29] (foces). Este cdigo utilizado no Laboratrio de Plasmas do IFUSP, no estudo e anlise de melhores parmetros de aquecimento, via ondas de Alfvn no tokamak TCABR (Tokamak Chauffage Alfvn Brazil). Este cdigo tem o seguinte sistema de arquivos:

forces, o executvel gerado depois da compilao do cdigo,

alfdata.txt e alfdata2.txt, arquivos de dados de entrada, e arquivos de sada, resultados das simulaes, como campo eltrico, campo magntico, impedncia, foras ponderomotoras, potncia dissipada, etc. A seguir, o sistema de arquivos dos dados de entrada e sada do cdigo forces:

Pode-se rodar dois jobs no Grid, um no site egeece02.ifca.es e outro no site CBPF:

Uma vez terminada a execuo dos jobs, obtm-se os dados gerados, para a conta do usurio. Define-se que os dados puxados sejam armazenados no diretrio Saida-forces, sendo que para cada job ser gerado um diretrio, como pode-se ver na continuao:

onde, bfields.dat, efields.dat, ener.dat, ftheta.txt, fxt.txt, imp.txt e pow.txt so dados gerados na simulao.

Guardando os dados: os dados gerados nas simulaes, so guardados no SE local epode-se replicar para mais de um SE, para aumentar a confiabilidade do sistema e evitar perda de dados. O LCG File Catalog (LFC) representa uma estrutura de arquivos em um nico diretrio, que independente da localizao fsica dos arquivos. Na verdade, um arquivo pode estar efetivamente em mltiplos SEs (mltiplas rplicas) mas, ainda assim, representado por uma nica entrada no LFC. Um arquivo considerado como um arquivo de Grid se ele estiver fisicamente presente em um SE e registrado no sistema de catlogos (LFC). Associado ao LFC h um conjunto de utilitrios chamado LCG-utils, que estabelecem um conjunto de mtodos para interagir (leitura/gravao, listar, criao/destruio de diretrios, etc.) com uma SE e manter o LFC em sincronia. Pode-se criar um diretrio forces, no SE local, para onde sero armazenados os dados:

Fazendo-se uma cpia, como exemplo, utiliza-se o arquivo efields.dat e bfields.dat, no SE local (se01.cat.cbpf.br). Os passos para efetuar a copia no diretrio forces, esto a seguir:

Fazendo uma rplica se2.egee.cesga.es:

dos

arquivos

efields.dat

e

bfields.dat

no

SE

escolhido,

O lcg-utils tem vrios comandos teis para a manipulao de arquivos. Como exemplo mostramos como apagado o arquivo bfields.dat (ser apagado de todos os Ses):

Para copiar um arquivo de uma SE e salv-lo na conta de usurio, procede-se da seguinte forma:

4.9.- Scripts Uteis: slc-script e c3Para uma boa administrao do site do CBPF foi instalado e criado alguns utilitrios, como scripts em Bash Shell (scl-script)[33] e python (c3)[34]. O slc-script consta de uma srie de scripts que automatizam a copia de arquivos, execuo de comandos, etc. simultaneamente em todas as mquinas do cluster. Por exemplo: ce01# scl-scp '/root/site-info.def /root'

este comando copia o arquivo site-info.def da mquina ce01 para o /root de todas as mquinas do cluster. Outro exemplo: ce01# scl-exec 'service sshd restart'

este comando reinicializa o servio sshd em todas as mquinas do cluster. Os scripts do scl executam o comando de forma linear, ou seja, depois de executado o comando numa mquina passa para a seguinte ate chegar a ltima mquina. No caso do c3 so scripts mais interessantes, a execuo feita simultaneamente em todas as maquinas. O c3 consta de vrios comandos, por exemplo: ce01# cexec :01-21,29,32,34-40 service sshd restart Para que funcione automaticamente estes comandos, ou seja, sem pedir senha, necessrio gerar chaves para os usurios root de todas as mquinas e sincroniza-las todas elas. gerado as chaves, por exemplo no ce01 e copiado para o wn01: ce01# ce01# ce01# ce01# ssh-keygen -t rsa -N '' '' -q -f /root/.ssh/id_rsa ssh-keygen -t dsa -N '' '' -q -f /root/.ssh/id_dsa ssh-copy-id -i /root/.ssh/id_dsa.pub wn01 ssh-copy-id -i /root/.ssh/id_rsa.pub wn01

Se tem que repetir este procedimento para todas as mquinas do cluster.

4.10.- Clculo das Necessidades de Refrigerao e Carga para o Grid CBPF/LAFEX4.10.1.- Factores

A rea til da sala O tamanho e a posio das janelas, e se elas tm persianas ou cortinas O nmero de ocupantes da sala (se houver) O calor gerado pelos equipamentos O calor gerado pela iluminao

4.10.2.- Equipamentos Consideraremos, para fazer uma estimativa do consumo de energia, mquinas servidoras com as seguintes caractersticas:

Processador Intel Xeon Quad-Core E5430 2,66 GHz 8 GB de RAM 667 MHz HD SATA 3.5 160 GB 7200 RPM Duas interfaces de rede Gigabit DVD ROM SATA Placa me Intel e perifricos.

Outros equipamentos:

Switchs KVM Monitor lmpadas

Como estas mquinas sero montadas, no h uma especificao nominal do consumo de energia. Medies da intensidade de corrente, feitas em condies de CPU Intensive para um servidor com as caractersticas de acima e com um processador Xeon E5310 1,6GHz (mquinas servidoras do Grid CBPF/LAFEX), mostrou um consumo de 1,8 a 1,9A (medio feita por Renato e Anderson 01/2008). Salientamos que, este valor de intensidade de corrente no teve significativa diferena entre mquinas 3U e TORRE. A DELL, disponibiliza uma ferramenta online para o clculo de consumo de energia dos servidores que vende[35]. Utilizaremos esta ferramenta para fazer nossa estimativas para mquinas com a configurao mostrada acima (quando for possvel).

Fig 24: Consumo de energia do servidor DELL modelo T610.

Fazendo uma estimativa em CPU intesive, para uma mquina servidora com caracterstica aproximada especificada acima (modelo TORRE), temos os seguintes resultados, figura 24: Na figura 24 vemos um consumo de 229,4 Watts (7.826,6 BTU/h) com 2,1A. Esta estimativa se fez para um servidor Xeon E5506 2,4GHz, HD 160 SATA 7200 RPM, 8 GB RAM 1066MHz, DVD ROM, e demais perifricos. Para 63 servidores (504 CPUs) mostramos na figura 25 os dados obtidos.

Fig 25: Energia consumida por 504 CPUs Modelo T610.

Vemos, para 504 CPUs um consumo de 14.450,0 Watts (49.305,5BTU/h) e 134A. Para a situao de 1000 CPUs necessrio duplicar estes valores. A carga para cada servidor podemos definir em um valor de 230 Watts. 4.10.3.- Estimativa em BTUs [36,37,38]

A rea til da sala: BTU rea sala = comprimento (m) x largura (m) x 337

O tamanho e a posio das janelas, e se elas tm persianas ou cortinas: BTU Janela Sul = comprimento da janela face sul (m) x largura (m) x 870 BTU Janela Norte = comprimento da janela face norte (m) x largura (m) x 165. Se no houver persianas nas janelas multiplicar os resultados por 1,5. Para casos do hemisfrio sul, trocar a ordem.

O nmero de ocupantes da sala (se houver): BTU de ocupantes = Nmero de ocupantes x 400.

O calor gerado pelos equipamentos: BTU equipamentos = total de Watts de todo os equipamentos x 3,5. Neste total entram Watts dos servidores, switchs, KVMs, monitores, ruteadores, etc.

O calor gerado pela iluminao: BTU iluminao = total de Watts de toda a iluminao x 4,25

4.10.4.- Converses

1 Watt = 3,412 BTU. Para um servidor de 230 Watts teriamos 784,76 BTUs VA a Watts [39,40]: VA x FP = Watts Encontrar o fator de potncia (FP) requer alguns clculos que no mostraremos aqu [41,42]. Para computador a correo do fator de potncia geralmente superior a 90%. Para motores de alta potncia sob carga pesada o fator de potncia pode ser to baixa quanto 35%. recomendado utilizarr para computadore o FP de 85%.

Ento para um servidor, com as caratersticas mostradas acima, seo (2), o sistemas de alimentao inenterrompida seria: 230 Watts / (0,85 Watts/VA)= 270 VA

4.10.5.- Total de Refrigerao Requerida Total de BTU = BTU rea sala + BTU Janela Sul + BTU Janela Norte + BTU de ocupantes + BTU equipamentos + BTU iluminao. Clculo para uma sala de 7,15m x 3,30m x 2,10m com uma jalena leste de 2,85m x 1,20m; 504 CPUs (63 servidores), nenhum ocupante, 6 nobreaks, 1 KVM, 2 Monitores, 4 switchs, sem iluminao constante. Total de BTU = 7,15 x 3,30 x 337 + 2,85 x 1,20 x (870+165)/2 + = 65.661,25 BTU Esta a quantidade de refrigerao necessria. Foi considerado uma media de 500 Watts para os nobreaks, monitores, KVM e switchs. (rea da sala) (rea da Janela)

(63 x 784,76 + 13 x 500 ) (servidores, nobreaks, monitores, KVM, switchs)

4.11.- Temperatura externaMonitorar a temperatura externa importante, j que tendo essa informao podemos tomar medidas preventivas referente a refrigerao necessria. Para a medida da temperatura externa utilizaremos o circuito mostrado na figura 26.

Fig 26. Esquema de circuito para medio de temperatura.

Este circuito consta das seguintes partes: - Um bus de rede Dallas 1-Wire - Interface entre o RS-232 e o sistema Dallas 1-Wire - Sensores digitais conectados ao bus Dalas 1-Wire (DS1820/DS18s20) - Software DigiTemp [43] e instalao de recolector e gerador de grfico de temperaturas

Fig 27. Medio da temperatura dos HDs dos WNs wn16 ao wn20.

A vantagem de este sistema que o circuito de medio de temperatura conetado na porta serial do computador e as temperaturas dos sensores conetados no cabo (que pode ser o cabo de rede cat5e) mostrado via linha de comando, desta forma facilitando a implementao de scripts addons para o ganglia. O sofware utilizado o digitemp. Uma vez implementado teremos medidas da temperatura similar ao mostrado na figura 27.

5 - RESULTADOS OBTIDOS EM FUNO DO PLANO DE TRABALHO PROPOSTO: Os resultados obtidos foram muito satisfatrios, sendo que o Site CBPF agora est em plena produo das simulaes de Monte Carlo feitos pelo LCHb, como podemos ver na figura 7. Foi adquirido uma grande experiencia no que se refere a instalao, configurao, monitoramento, atualizao de pacotes, estrutura do Grid LCG, etc. Durante um estagio de 3 meses e meio no CERN. Foi adquirido experiencia na submisso de jobs ao Grid via Ganga utilizando o Cdigo do LHCb DaVinci. Foi adquirido tambm experiencia referente a submisso de jobs a VO fusion. 6 - PUBLICAES CIENTFICAS: Pelo momento no temos ainda publicaes no que se refere ao Grid do CBPF. 7 - CONCLUSES GERAIS :

Grid/CBPF est em produo contribuindo em 4% no ROC do CERN na VO do LHCb. Configuraes feitas no Grid/CBPF para usurios finais, onde os usurios podem submeter jobs via UI do Site CBPF. Adquisio de uma boa base terico-pratica na rea de computao em grid com enfase gLite utilizado pelo LCG/EGEE. Domnio na instalao, configurao e manuteno de um site LCG/EGEE, com topologia LHCb. Foi adquirido uma experiencia razovel na utilizaco dos softwares do LHCb. Domnio na monitorao do site via, gstat, gridmap, ganglia, nagios e scripts. Domnio na instalao de novos WN's em tempo de execuo. Foi adquirido bastante experiencia na atualizao do middleware gLite sem entrar o site em downtime. Foi submetido jobs do cdigo DaVinci ao grid via ganga a partir do UI do site do CBPF, mostrando a sua viabilidade de utilizao para os usurios locais. Foi submetido jobs de teste de cdigo cintico toroidal da Fsica de Plasmas ao grid na VO de fuso vi JDL a partir da UI do CBPF.

A computao em Grid uma realidade, graas ao projeto EGEE e seus colaboradores, sendo possvel usufruir de um poder computacional nunca antes visto. O Grid proporciona um enorme poder computacional para simulaes na rea de Fsica de Plasmas, dentre outras aplicaes, tais como: outras reas da Fsica, Biologia, Qumica, etc. A submisso de jobs partindo de uma interface de usurio (UI) foi visto. Graas ao middleware gLite, que abstrai a complexidade que est por trs do Grid, a submisso de jobs transparente e de fcil manipulao. Mostrou-se, como exemplo, a submisso de jobs bsicos, pouco elaborados, e jobs complexos utilizando JDL. Conclui-se, portanto, que possvel rodar cdigos pessoais complexos no Grid, desde que as atividades estejam relacionadas VO. H grupos, VOs, que tem seu prprio entorno grfico ou LCI de submisso de jobs, gerando desta forma uma maior abstrao para o usurio. Por exemplo, no caso do LHCb o GANGA [26] que adiciona esta abstrao. No caso da VO fusion, no momento no h uma interface grfica semelhante ao GANGA em desenvolvimento, donde se conclui que h a necessidade do desenvolvimento de tal interface.

Atualmente, no Brasil, h alguns grupos colaborando, disponibilizando poder computacional no EGEE, por meio do projeto LCG, habilitando VOs do LHC e outras. O CBPF o primeiro site do Brasil que habilita a VO fusion, alm das VOs do LHCb, BIOMED e CMS. Pode-se ver da figura 3 o poder computacional disponvel para a VO fusion, sendo que, com a participao de algumas CPUs, possvel fazer parte deste grupo. Foram submetidos, como exemplo, dois jobs do cdigo Cintico Toroidal no Grid, obtendo-se dados de sada para diferentes parmetros de entrada. Disto, v-se que pode-se rodar mltiplos jobs, em diferentes sites, para diferentes dados de entrada, onde toda a complexidade de submisso de jobs pode ser definida via JDL. Se o cdigo for implementado com bibliotecas MPI, tambm possvel rodar no Grid de uma forma transparente via JDL, quando o site suportar MPI. A computao em Grid, na rea de Fuso Nuclear, nova no Brasil, portanto h muito o que ser feito: desenvolvimento de cdigos orientados a computao em Grid, adaptar cdigos existentes para rodar no Grid, disponibilizao de recursos computacionais para a VO fusion, criao de interfaces grficas de abstrao para submisso de jobs, elaborao de cdigos complexos, na reas de Fsica de Plasmas, com a participao de vrios grupos de pesquisa e aproveitar todo o potencial oferecido pelo Grid.

Apndice APara configurar o gLite no CE, SE e UI necessrio que cada uma de estas mquinas possuam certificado digital. Este certificado obtido em https://brgridca.ic.uff.br/pub. O certificado tem que estar em formato *.pem, e copiado os dois arquivos (hostcert.pem e hostkey.pem) em /etc/grid-security/. O script yaim encontra-se em /opt/glite/ yaim/bin.. recomendvel deixar desabilitado o yumupdate automtico, para que no atualize o sistema automaticamente, isto pode desconfigurar alguns servios do gLite. A.1.- Instalao, Configurao e Update do CE Uma vez terminado a instalao do SL necessrio fazer update do sistema. Antes do update substitui-se os repositrios dos pacotes de /etc/yum.repos.d pelos repositrios do CERN (http://linuxsoft.cern.ch/scientific/4x e http://linuxsoft.cern.ch/cern/slc4X) que esto (ver Apndice B). O dag.repo tem que estar configurado com: enabled=1 gpgcheck=0 Feito isto atualizamos o sistema: ce01# yum update no processo de atualizao sai um erro de dependncia, gnemo-openssl o desinstalamos este pacote e repetimos o procedimento. Uma vez terminado a atualizao, necessrio rebootar a mquina para que use o novo kernel. ce01# reboot

Logo do reboot, procedemos a instalar o middleware gLite 3.1. Para configurar o gLite no CE, SE, WN e UI necessrios dos arquivos (ver Apndice B): /root/site-info.def /opt/glite/yaim/etc/group.confg /opt/glite/yaim/etc/users.confg /opt/glite/yaim/etc/wn-list.confg necessrio configurar um servidor de NTP, neste caso escolhemos o ce01. Todas as mquinas do cluster tem que estar sincronizadas com o ce01.

Instalao o gLitece01# yum install lcg-CA glite-BDII lcg-CE glite-MON gliteTORQUE_server glite-TORQUE_utils

Configurao o gLitece01# export GLOBUS_LOCATION=/opt/globus ce01# yaim -c -s site-info.def -n BDII_site -n lcg-CE -n glite-MON -n TORQUE_server -n TORQUE_utils

Update (atualizao)ce01#yum update lcg-CA glite-BDII lcg-CE glite-MON glite-TORQUE_server glite-TORQUE_utils

Repetir yaim.

montado como /opt/exp_soft via NFS o diretrio /opt/exp_soft do se01 para o ce01. colocado no /etc/fstab o ponto de montagem: x.x.x.x:/opt/exp_soft onde x.x.x.x o IP do se01. A.2.- Instalao, Configurao e Update SE Atualizamos os repositrios de /etc/yum.repos.d pelos do CERN (ver Apndice B). Copiamos do ce01 os arquivos: /root/site-info.def /opt/glite/yaim/etc/group.confg /opt/glite/yaim/etc/users.confg /opt/glite/yaim/etc/wn-list.confg /opt/exp_soft nfs auto 0 0

O dag.repo tem que estar configurado com: enabled=1 gpgcheck=0 se01# yum update se01# reboot

Instalando o gLite no se01 se01# yum install lcg-CA glite-SE_dpm_mysql glite-SE_dpm_dis

Configurando o gLite se01# export GLOBUS_LOCATION=/opt/globus se01# mkdir /data01 se01# /opt/glite/yaim/bin/yaim -c -s site-info.def -n SE_dpm_mysql -n SE_dpm_disk

Update (atualizao) se01# yum update lcg-CA glite-SE_dpm_mysql glite-SE_dpm_dis

Repetir yaim.

A.3.- Instalao, Configurao e Update da UI Atualizamos os repositrios de /etc/yum.repos.d pelos do CERN (ver Apndice B). Copiamos do ce01 os arquivos: /root/site-info.def /opt/glite/yaim/etc/group.confg /opt/glite/yaim/etc/users.confg /opt/glite/yaim/etc/wn-list.confg O dag.repo tem que estar configurado com: enabled=1 gpgcheck=0 se01# yum update se01# reboot

instalando o gLite na UIui# yum install glite-TORQUE_client lcg-CA glite-UI

Configurando o UI via yaim:

ui# yaim -c -s site-info.def -n glite-UI -n TORQUE_client

Update (atualizao) ui# yum update glite-TORQUE_client lcg-CA glite-UI

Repetir yaim.

montado como /opt/exp_soft via NFS o diretrio /opt/exp_soft do se01 para a UI. colocado no /etc/fstab o ponto de montagem: x.x.x.x:/opt/exp_soft onde x.x.x.x o IP do se01. A.4.- Instalao, Configurao e Update de WNs Mostraremos a instalao e configurao do gLite para o worher node 01 (wn01). Atualizamos os repositrios de /etc/yum.repos.d pelos do CERN (ver Apndice B). Copiamos do ce01 os arquivos: /root/site-info.def /opt/glite/yaim/etc/group.confg /opt/glite/yaim/etc/users.confg /opt/glite/yaim/etc/wn-list.confg O dag.repo tem que estar configurado com: enabled=1 gpgcheck=0 wn01# yum update wn01# reboot

/opt/exp_soft

nfs

auto

0

0

instalando o gLite no wn01wn01# yum install glite-TORQUE_client lcg-CA wn01# yum groupinstall glite-WN

Configurando o wn01 via yaim:wn0# yaim -c -s site-info.def -n glite-WN -n TORQUE_client

Update (atualizao) ui# yum update glite-TORQUE_client lcg-CA glite-WN

Repetir yaim.

montado como /opt/exp_soft via NFS o diretrio /opt/exp_soft do se01 para o wn01. colocado no /etc/fstab o ponto de montagem: x.x.x.x:/opt/exp_soft onde x.x.x.x o IP do se01. /opt/exp_soft nfs auto 0 0

Apndice BArquivos do gLite /root/site-info.def /opt/glite/yaim/etc/group.confg /opt/glite/yaim/etc/users.confg /opt/glite/yaim/etc/wn-list.confg Arquivos dos repositrios /etc/yum.repos.d/ Arquivos do c3 /etc/c3.confg Arquivos do ganglia /etc/gmond.conf /etc/gmetad.conf

Referncias[1] http://www.eu-egee.org/ [2] http://lcg.web.cern.ch/LCG/ [3] http://www.cern.ch/lhc [4] http://collaborating.eu-egee.org/index.php?id=400 [5] http://www.cbpf.br [6] http://gridmap.cern.ch [7] http://www.cern.ch [8] http://cic.gridops.org/index.php?section=home&page=volist [9] http://www3.egee.cesga.es/gridsite/accounting/CESGA/vodis_view.html [10] http://grid.bifi.unizar.es/egee/fusion-vo/partners.html [11] http://www3.egee.cesga.es/gridsite/accounting/CESGA/egee_view.php [12] http://goc.grid.sinica.edu.tw/gstat/CBPF/ [13] http://gridmon.cat.cbpf.br/ganglia/ [14] http://grid.bifi.unizar.es/wiki/doku.php?id=egee:fusionvo:join [15] https://wiki.roc-la.org/RocLA [16] http://alien.cern.ch/twiki/bin/view/AliEn/Home [17] http://www.openssh.org/ [18] http://castor.web.cern.ch/castor/ [19] F. Castejn, et. al., Memorandum of Understanding, for the EGEE Applications, Version 1.3, 2005, https://cic.gridops.org/common/all/documents/MOU/MOU-Fusion-V1.3.pdf. [20] http://glite.web.cern.ch/glite/ [21] http://glite.web.cern.ch/glite/documentation/default.asp [22] http://www.cs.wisc.edu/condor/ [23] http://www.openldap.org/ [24] E. R. Rondn, Teoria e Modelamento Computacional de Aquecimento de Plasma por Ondas de Alfvn no Tokamak TCABR,Tese de doutorado apresentada no IFUS