public marks

PUBLIC MARKS from holyver with tag server


Puppet versus Chef: 10 reasons why Puppet wins | Bitfield Consulting

Puppet, Chef, cfengine, and Bcfg2 are all players in the configuration management space. If you’re looking for Linux automation solutions, or server configuration management tools, the two technologies you’re most likely to come across are Puppet and Opscode Chef. They are broadly similar in architecture and solve the same kinds of problems. Puppet, from Reductive Labs, has been around longer, and has a large user base. Chef, from Opscode, has learned some of the lessons from Puppet’s development, and has a high-profile client: EngineYard.

3.4 million page views per day, 92 M per month, one server and Drupal

In this talk, Khalid of, Inc., Inc will talk about a how to scale a Drupal web site with the following statistics. 3.4 million pages per day peak 92 million page views per month 189,650 page views per hour peak 840,000 visits on peak day 22.96 million visits per month 52,747 visits per hour peak So far, this is the highest traffic a Drupal site gets that we heard of. What is amazing is that this web site runs on a single mid range server ...


How to benchmark, Stress, your Apache, Nginx or IIS server | Linux Operating System - Debian, Ubuntu, Fedora, Gentoo, Arch

by 1 other
Actually usually any web server can handle a normal day of work, but what happens when the server under your administration gets, stumbled, or appears in Slashdot, or digg front pages, now a days even twitter may drive a lot of traffic to a webpage.


Shindig - Welcome To Shindig!

by 4 others (via)
What is Shindig? Shindig is a container for hosting social application consisting of four parts: * Gadget Container JavaScript: core JavaScript foundation for general gadget functionality (read more about gadget functionality). This JavaScript manages security, communication, UI layout, and feature extensions, such as the OpenSocial API. * Gadget Rendering Server: used to render the gadget XML into JavaScript and HTML for the container to expose via the container JavaScript. * OpenSocial Container JavaScript: JavaScript environment that sits on top of the Gadget Container JavaScript and provides OpenSocial specific functionality (profiles, friends, activities, datastore). * OpenSocial Data Server: an implementation of the server interface to container-specific information, including the OpenSocial REST APIs, with clear extension points so others can connect it to their own backends. Shindig is the reference implementation of OpenSocial API specifications, a standard set of Social Network APIs which includes: * Profiles * Relationships * Activities * Shared applications * Authentication * Authorization


Squid Reverse Proxy

This document describes reverse proxies, and how they are used to improve Web server performance. Section 1 gives an introduction to reverse proxies, describing what they are and what they are used for. Section 2 compares reverse proxy caches with standard and transparent proxy caches, explaining the different functionality each provides. Section 3 illustrates how the reverse proxy actually caches the content and delivers it to the client. Section 4 describes how to configure Squid as a reverse proxy cache.

The OpenLDAP Proxy Server

As stated previously, an LDAP proxy server accesses services (in our case, LDAP services) on behalf of a client's request. This architecture is used frequently if the user is behind a firewall and wishes to access resources outside, normally on the Internet. More generally, the LDAP proxy provides a way of giving controlled access via the LDAP protocol to resources outside the actual domain; therefore, you may use it to join different domains in your intranet (e.g., different LANs located in different countries of your enterprise intranet).


Cluster Architectures

This following sections describe alternative architectures for a WebLogic Server cluster: * Architectural and Cluster Terminology * Recommended Basic Architecture * Recommended Multi-Tier Architecture * Recommended Proxy Architectures * Security Options for Cluster Architectures

Integration continue - XP-Swiss

Avant de commencer avec l'intégration continue, il faut comprendre l'architecture "idéale" de développement d'une application. Elle se compose de cinq environnements : * les postes des développeurs (dits "locaux"), avec les différents outils traditionnels (IDE, outils de modèlisation de base de données, éditeurs XML, ...) * l'environnement de développement. Il est réservé aux développeurs qui en ont tous les droits (administrateurs). On verra que c'est l'environnement cible de l'intégration continue. Il est ainsi toujours à jour avec la dernière version disponible de l'application. De plus son état est souvent plus ou moins stable (redémarrage fréquent des applications, données volatiles insérées par les développeurs dans le cadre de leurs tests, ...) * l'environnement de test à destination du client (par exemple l'équipe marketing). Ce dernier valide le bon développement de l'application par rapport à ses besoins. Dans le cadre d'un développement itératif, il permet surtout de découvrir à temps les besoins réels du client qui sont trop souvent mal exprimés ou incomplets. Une nouvelle version de l'application est déployée depuis l'environnement de développement dès que l'appli est estimée stable et qu'elle contient suffisement de nouveautés ou corrections de bugs par rapport à la version précédente. Ces déploiements sont tout de même fréquents (toutes les 1 à 2 semaines) et sont généralement effectués manuellement à la demande du chef de projet. On offre alors généralement un fichier changes.txt qui décrit les différentes évolutions et corrections de bugs apportées depuis la version précédente. * l'environnement de pré-production pour tester la version finale de l'application. Il reproduit à l'identique l'environnement de production (nombre de machines, processeurs, mémoires, versions des applications, ...). Il permet de réaliser les tests de charge et de valider la bonne exécution de l'application lors du passage en production. * l'environnement de production accessible par les clients.

DRBD in a Heartbeat | Linux Journal

This high-availability solution works by replicating a disk partition in a master/slave mode. The server that is running as a master has full read/write access to that partition; whereas the server running as slave has absolutely no access to the partition but silently replicates all changes made by the master server.

Setting Up A Highly Available NFS Server | HowtoForge - Linux Howtos and Tutorials

In this tutorial I will describe how to set up a highly available NFS server that can be used as storage solution for other high-availability services like, for example, a cluster of web servers that are being loadbalanced. If you have a web server cluster with two or more nodes that serve the same web site(s), than these nodes must access the same pool of data so that every node serves the same data, no matter if the loadbalancer directs the user to node 1 or node n. This can be achieved with an NFS share on an NFS server that all web server nodes (the NFS clients) can access.

Consolidation and virtualization: The same, but different

Many IT administrators have discovered that there is overlap between consolidation and virtualization, and they are wondering how they should reconcile these two techniques in datacenter environments. Virtualization tools such as partitions, virtual machines, and resource management software all enable multiple dominant workloads to run simultaneously on larger servers, which is typically a key aspect of consolidation. But virtualization also offers far-reaching opportunities for administrators to fundamentally transform the operations in their datacenters.