[FUG-BR] Particionamento FreeBSD 10.1
Patrick Tracanelli
eksffa em freebsdbrasil.com.br
Terça Maio 19 15:07:06 BRT 2015
> On 19/05/2015, at 14:05, Paulo Henrique - BSDs Brasil <paulo.rddck em bsd.com.br> wrote:
>
>
> On 05/19/15 13:45, Patrick Tracanelli wrote:
>>> On 18/05/2015, at 20:19, Paulo Henrique - BSDs Brasil <paulo.rddck em bsd.com.br> wrote:
>>>
>>>
>>> On 05/18/15 19:58, Patrick Tracanelli wrote:
>>>>> On 18/05/2015, at 19:18, Samuel . <lista.freebsd.brasil em outlook.com> wrote:
>>>>>
>>>>> Patrick, todos sabem, você é o cara! Muitíssimo obrigado pelo comentário.
>>>> Hahaha não sou não, só me coloquei na situação de usuário do seu servidor :D
>>>>
>>>>> Com base nessas informações, vou reformular totalmente o cenário aqui.
>>>>> Não abusando da sua boa vontade. Mas eu tenho um SSD de 120 GB e um HDD de 250, queria poder usar os dois para ter espaço sobrando.
>>>>> Qual layout de particionamento você recomenda?
>>>> Minha recomendação principal, o que eu faria, foi oq mencionei em uns e-mails pra trás, levantar quais estruturas existem mais operações e colocar esses pontos de montagem no SSD. Ou seja o layout de mount points deve ser apontado por esse levantamento…
>>>>
>>>> Mas como eu mencionei também antes, se voce ja sabe que é samba o serviço principal você ja deve ter alguma ideia, mesmo sem olhar estatísticas, de quais shares são os mais críticos em termos de performance.
>>>>
>>>> Então eu teria todas as partições no HDD, incluindo o /usr/home e teria um outro volume (se for zfs) ou ou mpoint se for UFS, digamos /usr/home2 e esse com o SSD. Todos os shares críticos em termos de performance estaria no SSD, digamos (um chute) /usr/home2/producao, /usr/home2/desenvolvimento, e os demais no HDD mesmo.
>>>>
>>>> Ou seja difícil sugerir sem conhecer a estrutura funcionam da empresa, mas com certeza voce tem subsídios pra mapear e descobrir isso.
>>>>
>>>> Se ja existir um server com essa função hoje, faça o levantamento estatístico no atual.
>>>>
>>>> Por exemplo, olhando com fstat no servidor aqui da empresa eu vejo que a maior parte das operações de I/O acontecem no /usr/home e no /nfs. O “top -mio -o total” me confirma essa noção, mostrando que os processos que mais fazem I/O são httpd, nfsd e sshd (nego adora scp aqui hehehe) e depois o postgres.
>>>>
>>>> Então aqui no servidor que atende a galera da empresa, certamente se fosse pra ter um SSD ele seria no /nfs e no /usr/home.
>>>>
>>>> Mas se o SSD não for grande suficiente, vou olhar com lsof, nfsstat e procstat pra saber quem são os que mais fazem esses acessos, e descubro que no meu caso os que mais fazem I/O são:
>>>>
>>>> /usr/home/svn
>>>> /usr/home/honorato
>>>>
>>>> Bom no momento aqui parece que quem mais se beneficiaria de um SSD seriam o usuário honorato e o Subversion ja que são os top I/O.
>>>>
>>>> Ou seja esse é o perfil que você tem que mapear. Não existe uma receita de bolo pq cada server tem os usuários que merece hehehe ;) Às cegas eu sugeriria o /usr/home no SSD mas se for insuficiente os 120G você precisa ter um plano pra mapear quem fica num /usr/home2 e quem fica num /usr/home, sendo um HDD outro SSD.
>>>>
>>>> Se for usar zfs use esse script dtrace pra ter estatísticas por dataset: https://github.com/kdavyd/dtrace/blob/master/zfsio.d
>>>>
>>>> []s
>>> Aproveitando e engajando na conversa, lembro no passado o ZFS ter suporte a SSD para nivel de cache ( ARC2 ou trim se não me engano ), como não sou adepto dele ( começamos com o pé esquerdo apos uma queda de energia ter perdido todas as minhas musicas ) não posso afirmar se há esse recurso mesmo e se o nome deles é um dos anteriormente citados com plena certeza alguém ai que usa e pode confirmar?
>> É isso ai, o ZIL que é o cache de escrita (na verdade é o logging das operações de metadata, típico de FS jornada) e L2ARC que é o cache de leitura. Ambos podem ser metidos no SSD sim, seria algo como (assumindo que SSD seja de 120G no ada2 que é a situação do Samuel e ele queira 8G pro L2ARC e 20 pro ZIL e o resto pro samba):
>>
>> gpart add -t freebsd-zfs -a 4k -l log -s 8G ada2
>> gpart add -t freebsd-zfs -a 4k -l cache -s 20G ada2
>> gpart add -t freebsd-zfs -a 4k -l home2 -s 92G ada2
>> zpool create zstore gpt/home2 log gpt/log cache gpt/cache
>>
>>
>
> No caso seria possivel manter o home no HDD em tratar o cache e log só no SSD ?
Certamente, só é espaço demais… 120G de SSD pra L2ARC+ZIL = desperdício e SSD que nunca será tocado. Lembre-se ZIL é meta-dados e L2ARC é L2, ou seja tem um estágio de Cache que é feito antes na RAM pra so depois ir pra disco.
> Creio que para o que ele possua seja mais interessante.
Eu discordo vai voltar ao ponto de desperdício ehehe, o benefício será sempre mais sentido se a aplicação crítica tirar proveito do SSD primariamente.
Mas enfim acho que a discussão ja deu subsídios suficiente agora é partir pra decisão do que fazer :D
> Supondo que o HDD dele seja o ada3.
>
> gpart add -t freebsd-zfs -a 4k -l log -s 38G ada2
> gpart add -t freebsd-zfs -a 4k -l cache -s 82G ada2
> gpart add -t freebsd-zfs -a 4k -l home -s 200G ada3p3 ( Considerando que ele deixe 200Gbytes para o home no servidor sobre o HDD e separado do / e swap, normalmente eu separo o /usr, /var e /tmp tambem )
> zpool create zstore gpt/home log gpt/log cache gpt/cache
>
> Particionamento do HDD seria
> / => (TAM=(HOME - (SWAP*2)))G => ada3p1
> swap => RAM*2 => ada3p2
> /home => 200G => ada3p3
>
> Att.
>>
>>
>>> Samuel, não irá colocar nenhum recursos de resiliencia no seu HDD ? se não for colocar coloca todos os dados no SSD simplesmente devido a probabilidade de falha dele comparado com o HDD é bem menor.
>>> E aproposito qual o modelo do seu HDD ? se for qualquer HDD de desktop eu desencorajo a utilização, usei muito no passa e ainda tenho dois servidores usando discos da Western Digital contudo o que perco de desempenho e resistencia de operação com eles não vale a pena a economia.
>>>
>>> Att.
>>>
>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Att,
>>>>> Samuel .Rio Grande do Sul - RS
>>>>>
>>>>>> From: eksffa em freebsdbrasil.com.br
>>>>>> Date: Mon, 18 May 2015 12:11:38 -0300
>>>>>> To: freebsd em fug.com.br
>>>>>> Subject: Re: [FUG-BR] Particionamento FreeBSD 10.1
>>>>>>
>>>>>>
>>>>>>> On 17/05/2015, at 21:03, Samuel . <lista.freebsd.brasil em outlook.com> wrote:
>>>>>>>
>>>>>>> Olá!
>>>>>>> Primeiramente obrigado pelas excelentes respostas.
>>>>>>> Eu pensei em usar o SSD para o sistema operacional e o HDD para /home, /var e /tmp. Assim, penso eu, poupo um pouco a sobrecarga no SSD e consequentemente aumento a vida útil dele.
>>>>>>>
>>>>>> Você não está poupando está desperdiçando…
>>>>>>
>>>>>> Está deixando de andar de Ferrari pra andar de Gol pq a manutenção é mais barata.
>>>>>>
>>>>>> Só que a Ferrari não vai quebrar toda semana, só vai ser mais caro quando quebrar. Se é pra não tirar da garagem melhor não ter. Se é pra não usar seu SSD e tirar tudo que ele pra oferecer durante toda a vida útil dele, melhor não ter um SSD só pq ele vai ter uma vida útil 80% menor.
>>>>>>
>>>>>> Como eu disse no outro e-mail, ter SSD e HDD no seu servidor e usa-los intensamente, na mesma proporção, é provável que você nunca veja seu SSD morrer (a não ser que seja um SSD antigo das primeiras gerações), e troque o servidor como um todo antes disso acontecer. Mas se o perfil de uso for tão intenso que o SSD morreu 20% antes do tempo, terá valido cada centavo antecipar uma troca de SSD 20% antes do tempo do HDD.
>>>>>>
>>>>>> Seu sistema operacional não precisa de um SSD! Quem precisa são seus dados, o volume crítico da aplicação crítica. Seu kernel estará sempre em memória e ter um SSD pra carregar seu /bin/ls ou /sbin/ifconfig num read mais rápido pra memória não tem vantagem nenhuma, além do que os arquivos mais comuns do SO já ficam em cache de RAM mesmo…
>>>>>>
>>>>>> Se eu fosse usuário do seu servidor e soubesse que meu /home está num HDD lento e o resto do FreeBSD num SSD mega rápido eu tenho duvida se ficaria triste ou revoltado hehehe ;) Mas certamente não seria um usuário feliz e satisfeito nem acharia que o investimento no SSD valeu a pena pra qualidade geral do serviço prestado por esse servidor!
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Att,
>>>>>>> Samuel .Rio Grande do Sul - RS
>>>>>>>
>>>>>>>> From: eksffa em freebsdbrasil.com.br
>>>>>>>> Date: Sun, 17 May 2015 14:37:32 -0300
>>>>>>>> To: freebsd em fug.com.br
>>>>>>>> Subject: Re: [FUG-BR] Particionamento FreeBSD 10.1
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>>> On May 17, 2015, at 2:14 PM, Nilton Jose Rizzo <rizzo em i805.com.br> wrote:
>>>>>>>>>
>>>>>>>>> Tenho uma dúvida em relação ao uso de ssd ...
>>>>>>>>>
>>>>>>>>> Como anda a durabilidade deles? Já é seguro utiliza-los
>>>>>>>>> em produção para grande massa de dados? como ficaria esta
>>>>>>>>> durabilidade caso tivesse apenas o SSD e utilizasse o sistema
>>>>>>>>> fazendo a atualização do src e ports semanalmente?
>>>>>>>> Hoje em dia creio que seja besteira se preocupar com a vida útil de um SSD, um SLC suporta mais ciclos de escrita que um HDD e um MLC tem expectativa de durar 80% dos ciclos de escrita de um HDD, ou seja se a expectativa de 7 anos do HDD bate com seu perfil de escrita em disco o SSD seria de 5.6 anos mas um servidor ou laptop como um todo, o mercado trabalha com expectativa de 5 anos até ser substituído.
>>>>>>>>
>>>>>>>> Ou seja todos que só tem SSD num laptop dificilmente verão seu SSD morrer antes de apoderarem a máquina como um todo.
>>>>>>>>
>>>>>>>> Mesma coisa pra maioria dos perfis de servidor em especial os perfis de uso onde a leitura é a maior parte das operações. SSD MLC duram menos ciclos de escrita mas duram mais ciclos de leitura.
>>>>>>>>
>>>>>>>> Ou seja apenas um SGDB com muita escrita ou um servidor de cache veria um SSD MLC morrer 1/5 do tempo antes de um HDD mas convenhamos ganhou tanto em performance que morrer e substituir por outro 20% mais rápido justifica casa centavo :)
>>>>>>>>
>>>>>>>> Antes era gambi, os sistemas operacionais (file system) tinham que se preocupar em fazer wear leveling pra poupar a vida dos SSD etc, hj o próprio drive cuida desses aspectos hehehe do mesmo modo que no passado tínhamos que rodar badsect e mapeadores de Bad block e hj os discos já os isolam sozinhos.
>>>>>>>>
>>>>>>>> Enfim a única coisa a se preocupar com SSD eh o preço :) o resto eh preciosismo hj em dia.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> /*************************************************
>>>>>>>>> **Nilton José Rizzo UFRRJ
>>>>>>>>> **http://www.rizzo.eng.br http://www.ufrrj.br
>>>>>>>>> **http://lattes.cnpq.br/0079460703536198
>>>>>>>>> **************************************************/
>>>>>>>>>
>>>>>>>>> -------------------------
>>>>>>>>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>>>>>>>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>>>>>>> -------------------------
>>>>>>>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>>>>>>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>>>>>>
>>>>>>> -------------------------
>>>>>>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>>>>>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>>>>> --
>>>>>> Patrick Tracanelli
>>>>>>
>>>>>> FreeBSD Brasil LTDA.
>>>>>> Tel.: (31) 3516-0800
>>>>>> 316601 em sip.freebsdbrasil.com.br
>>>>>> http://www.freebsdbrasil.com.br
>>>>>> "Long live Hanin Elias, Kim Deal!"
>>>>>>
>>>>>> -------------------------
>>>>>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>>>>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>>>>
>>>>> -------------------------
>>>>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>>>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>>> --
>>>> Patrick Tracanelli
>>>>
>>>> FreeBSD Brasil LTDA.
>>>> Tel.: (31) 3516-0800
>>>> 316601 em sip.freebsdbrasil.com.br
>>>> http://www.freebsdbrasil.com.br
>>>> "Long live Hanin Elias, Kim Deal!"
>>>>
>>>> -------------------------
>>>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>> --
>>> Paulo Henrique.
>>> BSDs Brasil - FUG-BR.
>>> Grupo de Usuários de FreeBSD do Brasil.
>>> Fone: (21) 96713-5042
>>>
>>> "Por mais breve que seja a loucura da fé, apegue-se a razão.
>>> Ela não tem todas as respostas porém não mente baseado na sua fé".
>>>
>>> -------------------------
>>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>> --
>> Patrick Tracanelli
>>
>> FreeBSD Brasil LTDA.
>> Tel.: (31) 3516-0800
>> 316601 em sip.freebsdbrasil.com.br
>> http://www.freebsdbrasil.com.br
>> "Long live Hanin Elias, Kim Deal!"
>>
>> -------------------------
>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>
> --
> Paulo Henrique.
> BSDs Brasil - FUG-BR.
> Grupo de Usuários de FreeBSD do Brasil.
> Fone: (21) 96713-5042
>
> "Por mais breve que seja a loucura da fé, apegue-se a razão.
> Ela não tem todas as respostas porém não mente baseado na sua fé".
>
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
--
Patrick Tracanelli
FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316601 em sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"
Mais detalhes sobre a lista de discussão freebsd